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(57) Abstract: The Passive Internet Cache ("PIC") system builds a global cache at or near end-user nodes, and substantially avoids 
response delays at end-user nodes arising from the exchange of request and response messages between a remote terminal and a 
hub node in a star topology network. Specifically, the PIC system "passively listens" using a secondary monitor (204) to all HTTP 
responses in an outbound channel (216) and enables end-user nodes interfaced with remote terminals (209) to use the contents of 
all HTTP responses in an outbound channel (216), reduces the repetitive transmission of the same HTTP response payloads over 
an outbound channel (216), and in dual channel networks also reduces the need to send HTTP requests over an inbound channel 
(214). The PIC system operates in any star topology network, including without limitation VSAT systems, Dircct-to-Home satellite 
systems, and multichannel multipoint distribution service. 
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TITLE OF THE INVENTION 
A SYSTEM AMD METHOD FOR A PASSIVE INTER>ffiT CACHE 
BACKGROUND OF THE INVENTION 
1. Field of the Invention 

The Passive Internet Cache system pertains to data caches in "star topology", dual 
channel (send and receive), and single channel (receive only, or "broadcast"), networks that 
5 use the HyperText Transfer Protocol ("HTTP"). HTTP is very commonly used with 
Transmission Control Protocol/Intemet Protocol ("TCP/IP") over the Internet or private 
networks that have a client/server architecture in which client software operated by an end 
user requests and receives information fix>m one or more server computers. The structure 
of such requests and responses conforms with the specifications for HriTP. HTTP 
10 specifications are currently promulgated by the World Wide Web Consortium, Cambridge, 
Massachusetts. 

An "HTTP requesf ' from a World Wide Web browser, or other software 
application that uses HTTP messages, to a server computer contains a Uniform Resource 
Locator ("URL") to identify the requested information. The data contents at the address 

15 specified by a URL can be a complete Webpage, or components of a Webpage (text, 
graphics, sound, video, or other type of file). The "HTTP response" from the server to the 
browser contains the "contents" of the URL, but normally does not restate the URL. The 
cache that is included with commonly available Web browsers interoperates with the 
browser as follows: (a) an end-user clicks on a URL displayed in a browser or other 

20 window of ihe display of an electronic device, usually a computer, coimected to the 
Internet; (b) the browser acts in conformity with the cache configuration settings of the 
browser, e.g., if the URL is stored in the built-in browser cache, the cache provides the 
contents of the stored URL to the browser imless required by the configuration settings to 
verify that the cached URL has not changed; if verification is required, or if the URL is not 

25 stored in browser cache, the cache sends an HTTP request message (usually including a 
"GET", or "GET IF-MODIFIED-SINCE" corranand) to request the URL from the host 
computer specified in the URL; (c) if the disk space used by browser cache exceeds a user- 
defined size, the cache deletes the oldest URLs in cache to acconunodate the newest URLs 
and their contents; and (d) upon receipt of the HTTP response to the HTTP request, the 

30 cache provides the response to the browser and stores the contents of the HTTP response 
in browser cache under the URL specified in the matching HTTP request. The IP packet 
of an HTTP request includes, among other filings, a GET (or other permitted) command, 
the requested URL, the IP address and TCP port number (collectively called the "source 
socket") of the end-user's computer, and the destination IP address and TCP port number 

35 (collectively called the "destination socket'O of the Webserver on which the URL resides. 
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The source socket of the HTTP request becomes the destination socket of the HTTP 
response, and the destination socket of the HTTP request becomes the source socket of the 
HTTP response. 

An HTTP request causes the Webserver identified in the request message (i.e., the 
5 host computer at the domain name specified in the URL in the HTTP request) to send a 
Webpage (or Webpage component) identified by the file component of the URL to the 
requesting browser. The Webpage (or Webpage component) sent by the identified 
Webserver is the payload of the HTTP response message. "Browser'' in this document 
means any end-user application software that uses HTTP. '*HTTP'* includes any equivalent 

10 or successor protocol to HTTP that performs "applications and services" fimctions at OSI 
layers 5 to 7 substantially similar to those of HTTP. "TCP/IP" includes any equivalent or 
successor protocol to TCP/IP that uses methods of message addressing, routing, transport, 
and headers that are substantially similar to those of TCP/IP. 

In noraial operation, a Web browser (or other software application that uses HTTP) 

1 5 only receives the contents of TCP/IP packets that contain (a) the destination IP address of 
the electronic device on v^ch the browser is numing, and (b) a TCP port number assigned 
to the Web browser application for the duration of the TCP connection by the operating 
system of the electronic device (or by other sofiware controlling the allocation of TCP 
ports on the device). "Electronic device" or "end-user node" means herein any type of 

20 compxitational device (a) under the control of an operating system, such as a personal 
computer ("PC"), set-top box, or Intemet appliance, and (b) that is inter&ced with a dual 
channel or single channel network. An end-user node can be used by a hvmian operator or 
be an unmanned processing node in a computer network. "End-user" means herein the 
client application (typically a browser) that originates HTTP requests and is the final 

25 recipient of HTTP responses. The most common network interfaces are network interface 
cards and dial-up networking adapters. In normal operation, a Web browser opens a TCP 
port, sends an HTTP request on that TCP port, and waits for an HTTP response on that 
TCP port. More accurately, the browser (or other client application sofiware) requests that 
the operating system assign to the browser (or other client application sofiware) an unused, 

30 unreserved TCP port number. The browser then uses that TCP port for a communications 
session. When the browser no longer needs the TCP port, the browser relinquishes the 
TCP port number (and therefore the TCP port the TCP port number identifies) back to the 
operating system, and the TCP port nimaber can be reassigned to another application. 
Approximately sixly-four thousand TCP ports are available, which enables a browser to 

35 obtain multiple, concurrent TCP ports and to conduct multiple, concurrent HTTP sessions. 
Typically, the operating system assigns TCP port nimibers in an ascending, sequential 
manner. When a TCP session is closed and the TCP port is released back to the operating 
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system, the same port number will normally not be \ised again until the operating system 
has cycled through the remaining (approximately 64,000) TCP ports. If the IP destination 
address of a packet available to a network interface of an electronic device does not match 
the (or an) IP address of the network interface, the network interface normally ignores or 
5 discards the packet. If the IP destination address does match the (or an) IP address of such 
network interface, the TCP/IP stack miming in the electronic device forwards the contents 
of the packet to the application (e.g., browser) that opened the TCP port identified in the 
TCP packet header. If the specified TCP port is not open, the packet is ignored or 
discarded. 

10 A traditional standalone cache (not part of a Web browser) matches an HTTP 

request with the HTTP response generated as a reply to the HTTP request, and stores the 
contents of the HTTP response under the URL specified in the HTTP request. The 
traditional standalone cache design requires collocation of the cache at a network access 
point where the cache can monitor and buffer traffic as required to provide the caching 

15 function. Being located at such a network access point permits a cache to monitor, copy 
and respond to HTTP requests and to store or cache HTTP responses that transit the access 
point. The caching device causes each HTTP request and each HTTP response to be stored 
in buffer memory and/or on a disk drive or other storage. When the URL is stored in the 
cache, the caching device accesses the bu£fered or cached information and responds to an 

20 HTTP request with the contents of the requested URL. If a URL is not stored in the cache, 
or when it is necessary to verify that the requested URL has not changed (which depends 
on specific cache configuration settmgs), the cache opens a TCP/IP connection to the 
designated Webserver (on a separate TCP port managed by the TCP/IP stack serving the 
cache) and returns an appropriate HTTP response to the originator of the HTTP request 

25 after receiving the HTTP response fi-om the Webserver. With traditional caching devices, 
the Webserver receives HTTP requests with IP headers containing the IP address and TCP 
port numbers assigned by the caching device rather than those of the originating device, 
such as an end-user node. 

The term "star topology, dual channel network" as used herein means satellite and 

30 terrestrial network architectures in which a plurality of transmit/receive ("TR'*) remote 
terminals share a return channel (called the outbound channel) transmitted from a central 
switching, or "hub", node to the remote terminals, and in vs^ch each TR remote terminal 
uses a uniquely assigned forward communications chaxmel (called the inbound channel) 
that is transmitted fi:om a TR remote terminal to the hub node and is not shared with (and 

35 is not received by) other remote terminals. Very small aperture terminal ("VSAT") 
satellite networks with transmit/receive ("two-way") remote terminals are an example of 
a star topology, dual channel network. In star topology, dual channel networks other than 
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two-way VS AT, the inbound channel from a TR remote temiinal to a hub node serving the 
TR remote terminal can be through a terrestrial network, such as by use of terrestrial 
microwave, copper pair, or fiberoptic media; the outbound channel can also be through a 
terrestrial network, such as in digital cablecast networks. All TR remote teraiinals can 
5 commimicate interactively with a hub node. 

The term "star topology, single channel network" as used herein means satellite and 
terrestrial network architectures in which a plurality of receive-only ("RO") remote 
terminals share a retum channel (called the "broadcast" or outbound channel) from a hub 
node, and in which each RO lemote temiinal lacks any inbound channel, direct or indirect, 

10 from an RO remote terminal to a hub node. VSAT satellite networks with receive-only 
("one-way") remote terminals are a common example of a star topology, single channel 
network. A "star topology" network, without qualification as to channels, means star 
topology network with a population of TR remote terminals, RO remote terminals, or a 
mixed population of TR and RO remote terminals. A "remote terminal" means a device 

15 that uses radio frequency, electrical, photonic, or other communications technologies for 
one-way (RO) or two-way (TR) commimications between that device and a hub node. A 
remote temiinal can be interfaced with one or more local area networks, or equivalent 
coimectivity, shared by end-user nodes and other types of nodes. 

A traditional, standalone cache interfaced with a TR remote terminal in a star 

20 topology, dual channel network can monitor (a) only the locally originated, remote 
terminal-to-hub node, inbound channel, and (b) a hub node-to-remote terminals, outbound 
channel. The locally originated inbound chaimel contains HTTP requests from end-users 
interfaced with the remote tenninal. The outbound chaimel contains HTTP responses to 
a plurality of remote temunals and the end-users interfaced with such remote terminals. 

25 A TR remote terminal in a star topology, dual channel VSAT network cannot directly 
monitor the inbound channels from other TR remote terminals to the hub node. An RO 
remote terminal in a star topology, single chaimel (broadcast) network does not have an 
inboxmd channel; there are no transmissions from the RO remote terminal to a hub node 
and therefore no inbound HTTP requests to monitor. An RO remote terminal also cannot 

30 directly monitor the inbound channels from other TR remote terminals to the hub node. An 
RO remote tenninal, however, may be interfaced with a local area network on which local 
HTTP requests are carried; a cache associated with an RO remote terminal can provide 
HTTP responses to local HTTP requests. Assuming a TR or RO remote terminal could 
receive HTTP responses addressed to other remote terminals, except in extremely rare 

35 instances described below, a traditional, standalone cache associated with such remote 
tenninal can not determine the URLs of such HTTP responses. 
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2. Descriptionof Related Art 

There are a great variety of caching technologies taught by prior art. Some caching 
methods are optimized for use in computer systems (U.S. Patent No. 5,930,515, issued to 
Ducharme, et al.), in Internet service provider operations (U.S. Patent No. 5,991,306, 
5 issued to Bums, et al.), or in satellite broadcasting (U.S. Patent No. 5,987,233, issued to 
Humphrey). The related art generally uses a "store and forward" approach in which files 
or data fix>m a source device (e.g., a Webserver) are replicated on one or more other 
storage devices, or caches. The refiresh fipequency and selection of files and data is 
operator-defined or based on the actual or predicted firequency with which the files or data 

10 have been, or will be, requested by end users. Cache refiresh can be either by the source 
initiating a refiresh and ^'pushing" files and data out to cache storage, or by a destination 
initiating a refi-esh and "pulling" files and data fi-om the source. Existing caching 
methods can be configured using varioiis rules for refireshing cache contents, for using 
drive space, for blocking specified URLs, etc. Such caches can also be configured for use 

15 as proxy servers, in which case an HTTP request generated by an end-user's browser uses 
a destination TCP port defined for the proxy server rather than using a well-known TCP 
port defined for public Webservers. TCP port 80 is a well-known port used by public 
Webservers for receiving HTTP requests. Caches can be cascaded, in which case each 
cache in series either contains the requested URL and retums the appropriate HTTP 

20 response to the requesting browser, or opens a TCP/IP connection to the next cache in 
series and sends an HTTP request to the next cache for the URL. In a cascaded cache 
architecture, wdien a cache does not contain a requested URL, the cache generates an HTTP 
request to the next device in series, and upon receipt of the HTTP response (which may 
come fi-om the next or subsequent cascaded caching device, or fix>m the Webserver at the 

25 end of the cascade), forwards the HTTP response to the end-user, or to a previous cache 
in a cascaded series of caches. 

- - -HTTP versions prior to HTTP 1.1 did not provide a field for the URL in the header 
of an HTTP response. The implication of this is that a device that monitors HTTP 
responses will not have access to the URL of the payload of an HTTP response when 

30 earlier versions of HTTP are used. This being the case, the URL and its contents cannot 
be cached when the HTTP request that generated the HTTP response is not available. 
When HTTP version 1 . 1 or later is used, the Content Location header (a field reserved in 
an HTTP response for flie URL of the payload of the response) is an optional field, and 
Webserver programmers are not required to include the field in the HTTP response. The 

35 use of the Content Location header is extremely rare; even when the Content Location 
header is included, the URL field may be missing or incorrect. When programmers do not 
include this field or the stated URL is missing or incorrect, an HTTP response cannot be 
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matched to the correspondmg URL unless the HTTP request is available. 

None of the caching technologies described in the related art addresses the problem 
of a remote terminal in a star topology network not having direct access to the inbound 
channels of other remote terminals, or of the omission of URLs in HTTP responses in 
5 outbound channels. Traditional, standalone caching technologies for star topology, dual 
channel networks, such as that described in U.S. Patent No. 5,987,233, issued to 
Humphrey, require that a ^'global'' standalone cache be maintained at one or more hub 
nodes (e.g., the hub earth station of a VSAT network) and that a remote terminal send 
HTTP requests through an inbound channel for all URLs that are not in the built-in 

10 browser cache, or other local cache, on a node interfaced with a remote terminal. The 
purpose of traditional caches, especially those associated with a hub node, is to reduce the 
volume of HTTP requests and HTTP responses transiting the span between the cache and 
the Internet, and therefore reduce the required datarate of (or increase the number of users 
supported over) such span. FIG. 1 depicts the current system of caching in a star topology, 

15 dual channel network. FIG lA illustrates message exchange when a URL is in a local 
cache. FIG IB illustrates message exchange when a URL is not in local cache or in a 
traditional hub cache. In addition, the use of a traditional cache at a hub node of a satellite 
networic provides a proxy function tiaat "intercepts*' end-users' HTTP requests for URLs, 
responds with those URLs cached at the hub node (which avoids Internet propagation 

20 delays), but does nothing to avoid the deterioration of response time due to satellite 
propagation delays between the end-user's node and the hub node. The contents of a 
"global" cache at a hub node reflect the activities of all end-users served by the hub 
node(s). In a multi-hub architecture, a "central" or "master" hub periodically collects the 
cache content from all other hub caches by pulling the contents from the hubs and creating 

25 an aggregate cache. The aggregate cache is then periodically pushed to the other hubs to 
replicate the aggregate cache at all hubs. In this architecture, the hub locations are 
generally terrestrial hubs, e.g. an internet service provider point of presence, with end-users 
supported via terrestrial (usually dial-up) access to the hub node. Locating a global cache 
at a hub node has been necessary because only a hub node provides a network access point 

3 0 that permits the monitoring of all HTTP requests from, and corresponding HTTP responses 
to, all remote terminals. Such caches generate, or obtain and relay, HTTP responses on 
behalf of client applications ruiming on end-user nodes. Providing global caches at 
intermediate nodes or at end-user nodes in a star topology network has heretofore required 
that the cache contents be actively pushed or pulled from the "master caching center" or 

35 global cache at the hub node(s). An "intermediate node" is a node between the hub node 
and an end-user node in a star topology network. Accordingly, there is a need for a more 
efticient and cost effective method and system of building a global cache at intermediate 
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nodes and at end-user nodes in star topology networks. 

The Passive Internet Cache system overcomes the limitation of having to collocate 
a global cache with the hub node(s) of a star topology network, and the limitation imposed 
by the omission of the URL in HTTP responses. The Passive Internet Cache system uses 
5 an innovative, "passive listening" method to construct a global cache at any intermediate 
node, at a series of cascaded intermediate nodes, or at end-user node in star topology 
networks. The Passive Intemet Cache system's provision of an HTTP response fix)m a 
global cache at or very near an end-user node means higher cache '"hit" rates for the end- 
user, faster response times, and a corresponding reduction in the use of inbound and 

1 0 outbound communication channels. 

SUMMARY OF THE INVENTION 
The Passive Intemet Cache ("PIC") system meets the need for a more efiQcient and 
cost effective global cache in intermediate nodes or end-user nodes in star topology 
networks. The PIC system builds a global cache at or near end-user nodes, and 

1 5 substantially avoids response delays at end-user nodes arising from the exchange of request 
and response messages between a remote terminal and a hub node. Specifically, the PIC 
system operates in the backgroxmd and enables end-user nodes interfaced with remote . 
terminals to use the contents of all HTTP responses in an outbound channel, reduces the 
repetitive transmission of the same HTTP response payloads over an outbound channel, 

20 and in dual channel networks also reduces the need to send HTTP requests over an inbound 
channel. The PIC system can be used and is effective in any type of star topology network. 
Suitable dual channel networks include VSAT systems with inbound and outbound 
channels by satellite, or with outbound channel by satellite and inbound channel by 
terrestrial network; Direct-to-Home ("DTH") satellite systems that have a broadcast 

25 outbound satellite chaimel and a terrestrial inbound channel (dial-up, leased line, cable 
modem, etc.); and terrestrial systems such as multichannel multipoint distribution service 
("MMDS"), local multipoint distribution service ("LMDS"), instructional television fixed 
service ("ITFS"), digital television broadcasting, and digital cablecasting systems that have 
a terrestrial 'broadcast" or "multicast" outbound chaimel and various types of inbound 

30 channels. '"Broadcast" means a single message in the outbound channel can be addressed 
to and received by all remote terminals. "Multicast" means a single message in the 
outboxmd channel can be addressed to and received by a portion of, but not all, remote 
terminals. In addition to star topology, dual chaimel networks, the PIC system is effective 
in networks with single channel, receive only terminals, such as receive-only VSAT and 

35 DTH satellite terminals. The PIC system is also effective with MMDS, LMDS, ITFS, 
digital television broadcasting, and digital cablecasting terminals that may have two-way 
(transmit/receive) or one-way (receive only) capabilities, whether wireline and/or wireless. 
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A PIC system can be configured to serve a mixed popxilation of TR remote terminals and 
RO remote terminals, and can be configured to use concurrently wireline outbound 
chaimels, wireless outbound channels, wireline inbound channels, and/or wireless inboimd 
channels. This document asstmies that end-users are associated with remote terminals and 
5 originate HTTP requests, and ihat Webservers (which may be on a local area network at 
the hub node, or may be accessed tiirough other networks serving the hub node) provide 
HTTP responses to the hub node, and the hub node transmits such HTTP responses in the 
outbound channel to the remote terminals. 

The Passive Intemet Cache system has five primary components: a monitoring 

10 component, an encapsulating component, a buffering component, an unencapsulating 
("decapsulating") component, and a global cache (called a "PIC Webcache"). A primary 
monitoring component and an encapsulation component are implemented at a hub node. 
A buffering component can be implemented at a hub node, intermediate node, and/or end- 
user node. The decapsulating component and the PIC Webcache are implemented at an 

15 intermediate node or at an end-user node of a star topology network. The decapsiilating 
component is interfaced or integral with a buffering component at an intermediate node or 
at an end-user node. An example of an intermediate node is a computer or set-top box 
interfaced with, or integral with, a VSAT, DTH, MMDS, LMDS, ITFS, digital television 
broadcasting, or digital cablecasting remote terminal and also interred with one or more 

20 end-user nodes; the inter&ces can be a local area network, a system bus, universal serial 
bus C^USB"), or similar connectivity. The distribution of the components of a PIC system 
defines the various embodiments of the invention. All embodiments of the PIC system 
require that a remote terminal ou^ut all HTTP responses received in the outbound channel, 
not just those HTTP responses with IP addresses assigned to intermediate nodes and end- 

25 user nodes interfaced with such remote terminal, to each instance of a secondary 
monitoring component associated with or interfaced with such remote terminal. Such 
output can be obtained by setting configuration options with some commonly available 
remote terminal or hub node systems. If a remote terminal and hub node system does not 
support reception of HTTP responses for nodes other than tiiose attached to a given remote 

30 terminal, additional hardware and/or software components, such as a signal splitter and 
separate receiver/decoder, must be added to provide the ability to receive all HTTP 
responses in an outbound chaimel at a remote terminal. 

One embodiment of the PIC system, in the context of a star topology, dual channel 
VSAT network, implements a primary monitoring component and an encapsulating 

35 component at a hub earth station, and implements a secondary monitoring component, a 
decapsulating component, a buffering component, and a PIC Webcache on an end-user 
node interfaced with a VSAT remote terminal. On the end-user node, the PIC Webcache 
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is configured as a proxy server cache and the Web browser is configured to use such proxy 
server cache. The primary monitoring component of the PIC system at the hub earth 
station monitors all inbound channels from all the VS AT remote terminals to the hub earth 
station. The primary monitoring component copies all HTTP requests from the monitored 
5 inbound chaimels, fr)rwards the HTTP requests to the encapsulating component at the hub 
earth station where the HTTP requests are immediately encapsulated in a User Datagram 
Protocol CXIDP") message. Such UDP messages are then immediately transmitted in the 
outbound channel using a broadcast IP address and UDP port monitored by all remote 
terminals that receive such outbound channel and are interfaced with an end-user node that 

10 has a PIC Webcache. The secondary monitoring component at the end-user node 
communicates through a network inter&ce on the end-user node with the VSAT remote 
terminal. The secondary monitoring component at the end-user node also communicates 
with the decapsulation component and with the buffering component on the end-usernode. 
The secondary monitoring component copies from the VSAT remote terminal to the 

15 decapsulation component all UDP messages, and to the buffering component all HTTP 
messages, received by the remote terminal, not just those packets with an IP destination 
address of the end-user node. When the secondary monitoring component on the end-user 
node receives a UDP packet containing an encapsulated HTTP request, it provides such 
packet to the decapsulation component. The decapsulation component removes the UDP 

20 encapsulation C^decapsulation"), and forwards the decapsulated HTTP request to the 
buffering component on the end-user node. The buffering component on the end-user node 
communicates with disk drive(s) or other read/write storage device(s) associated with the 
end user node that are used by the PIC Webcache for storage. The buffering component 
at the end-user node stores the decapsulated HTTP request in buffer memory, and opens 

25 a file (or database record) tagged with the source socket (source IP address and TCP port 
number) and the destination socket (destination IP address and TCP port number) specified 
in the decapsulated HTTP request. The tagged file (or database record) awaits the arrival 
of the relevant HTTP response to be delivered later by the buffering component 

Upon receipt at the hub earth station of an HTTP response from a Webserver, the 

30 hub eartti station transmits ih& HTTP response in the outbound channel. If a browser 
running on a end-user node interfaced with a VSAT remote terminal originated the HTTP 
request that generated the HTTP response, the HTTP response is received in the outbound 
channel by that VSAT remote terminal, forwarded to the PIC Webcache in the normal 
manner, and delivered by flie PIC Webcache, operating as a proxy server cache, to the 

35 requesting browser. The secondary monitoring component at the end-user node also 
forwards every HTTP response in the outbound channel to the buffering component 
running on the end-user node. If a browser nmning on an end-user node interfaced with 
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a VSAT remote terminal did not originate the HTTP request that generated the HTTP 
response, the contents of the HTTP response are not passed to the browser upon receipt 
Rather, the buffering component examines the HTTP response to determine the source and 
destination sockets and stores the contents of the HTTP response in the file (or database 
5 record) previously tagged with those sockets (but with source and destination sockets 
reversed in the HTTP request as compared with the HTTP response). After receiving both 
the HTTP request and tibe HTTP response, the buffering component at the end-user node 
can match the HTTP request with the correct HTTTP response, extract the URL identity 
from the HTTP request, and create a file (or database record) for ttie URL on the storage 

1 0 device(s) used by the PIC Webcache as if the browser itself had caused the PIC Webcache 
to cache the URL and its contents, but without displaying the URL contents and without 
issuing an HTTP request. To receive and store the HTTP response, the PIC system does 
not obtain or use a TCP port nxunber allocated by the end-user node or interfere with 
normal browser operation. If the browser requests a PIC-cached URL in the future, the 

15 contents of the URL will already be in the PIC Webcache, and will be delivered instantly 
from the PIC Webcache to the browser. 

In summary, the Passive Intemet Cache system without buffering at a hub node 
comprises a hub node of a star topology network that receives HTTP requests from one 
or more remote terminals, which hub node is interfaced with at least one external so^er 

20 computer and transmits UDP datagrams, HTTP requests, and HTTP responses in an 
outbound channel from said hub node of the star topology network, and one or more 
intermediate or end-user nodes of said network that receive said UDP datagrams, HTTP 
requests, and HTTP responses and which one or more intermediate or end-user nodes 
are associated with or interfaced with a means for socket-matching HTTP requests and 

25 HTTP responses and for storing in an end-user accessible cache the contents of a given 
HTTP response imder the URL extracted from a correctly matched HTTP request. 

The Passive Intemet Cache system with buffering at a hub node comprises a hub 
node of a star topology network that receives HTTP requests from one or more remote 
terminals, which hub node is interfaced with at least one extemal server computer, has a 

30 first means for socket-matching, and transmits UDP datagrams, HTTP requests, and 
HTTP responses in an outboimd channel from said hub node of the star topology 
network, and one or more intermediate or end-user nodes of said network that receive 
said UDP datagrams, HTTP requests, and HTTP responses and which one or more 
intermediate or end-user nodes are associated witib or interfaced with a second means 

35 for socket-matching HTTP requests and HTTP responses and for storing in an end-user 
accessible cache the contents of a given HTTP response under the URL extracted from 
a correctly matched HTTP request 

10 
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BRIEF DESCRIPTION OF THE DRAWINGS 

The foregoing and other aspects and features of the Passive Internet Cache system 
will be better understood from the following more detailed description and appended 
claims in conjunction with the drawings, of which: 

FIG. 1 illustrates the current system of caching in a star topology, dual channel 
network. 

FIG 1 A illustrates message exchange when a URL is in a local cache. 

FIG IB illustrates message exchange when a URL is not in local or hub cache. 

FIG. 2 illustrates the Passive Internet Cache embodiment with socket matching and 
PIC Webcache at an end-user node in a star topology, dual channel network (first 
embodiment). 

FIG. 2 A illustrates the distribution of PIC components in the first embodiment. 
FIG. 2B illiistrates passive listening and encapsulation at a hub node. 
FIG. 2C illustrates socket matching. 

FIG. 2D illustrates message exchange using socket matching to store URLs and 
URL contents in a PIC Webcache in the first embodiment. 

FIG. 3 illustrates the Passive Internet Cache embodiment with socket matching at. 
an intermediate node and with PIC Webcache at an end-user node in a star topology, dual 
channel network (second embodiment). 

FIG. 3 A illustrates the distribution of PIC components in the second embodiment. 

FIG. 4 illustrates tiie Passive Internet Cache embodiment with socket matching and 
PIC Webcache at an intermediate node in a star topology, dual channel network (third 
embodiment). 

FIG. 4 A illustrates the distribution of PIC components in the third embodiments 

FIG. 5 illustrates the Passive Internet Cache embodiment with socket matching at 
the hub node and with secondary buffering and PIC Webcache at an end-user node in a star 
topology, dual channel network (fourth embodiment). ^ , . . , . ; _ 

FIG. 5 A illustrates the distribution of PIC components in the fourth embodiment. 

FIG. 6 illustrates the Passive Internet Cache embodiment with socket matching at 
the hub node, with secondary buffering at an intermediate node, and with PIC Webcache 
at an end-user node in a star topology, dual chaimel network (fifth embodiment). 

FIG. 6A illustrates the distribution of PIC components in the fifth embodiment. 

FIG. 7 illustrates the Passive Internet Cache embodiment with socket matching at 
the hub node and with PIC Webcache at an intermediate node in a star topology, dual 
channel network (sixth embodiment). 

FIG. 7 A illustrates the distribution of PIC components in the sixth embodiment. 

FIG. 8 illustrates the Passive Internet Cache embodiment with socket matching and 



11 



wo 01/88761 



PCT/USOl/15575 



PIC Webcache at an end-user node in a star topology, single channel network (seventh 
embodiment). 

FIG. 8 A illustrates the distribution of PIC components in the seventh embodiment 

FIG. 9 illustrates the Passive Internet Cache embodiment with socket matching at 
an intermediate node and >vith PIC Webcache at an end-user node in a star topology, single 
channel network (eighth embodiment). 

FIG. 9A illustrates the distribution of PIC components in the eigihth embodiment. 

FIG. 10 illustrates the Passive Internet Cache embodiment with socket matching 
and PIC Webcache at an intermediate node in a star topology, single channel network 
(ninth embodiment). 

FIG. lOA illustrates the distribution of PIC components in the ninth embodiment 

FIG. 1 1 illustrates the Passive Internet Cache embodiment with socket matching 
at the hub node and with secondary buffering and PIC Webcache at an end-user node in 
a star topology, single channel network (tenth embodiment). 

FIG. 1 1 A illvistrates the distribution of PIC components in the tenth embodiment. 

FIG. 12 illustmtes the Passive Intemet Cache embodiment with socket matching 
at the hub node, with secondary buffering at an inteimediate node, and with PIC 
Webcache at an end-user node in a star topology, single channel network (eleventh 
embodiment). 

FIG. 12A illustrates the distribution of PIC components in the eleventh 
embodiment. 

FIG. 13 illustrates the Passive Intemet Cache embodiment with socket matching 
at the hub node and with secondary buffering and PIC Webcache and at an intermediate 
node in a star topology, single channel network (twelfth embodiment). 

FIG. 1 3 A illustrates the distribution of PIC components in the twelfth embodiment. 

FIG. 14 is a block diagram of intermediate node and end-user node functional 
modules in a star topology, dual channel network. 

FIG. 14A is a block diagram of hub node ftmctional modules node in a star 
topology, dual channel network. 

FIG. 15 is a block diagram of intermediate node and end-user node functional 
modules in a star topology, single channel network. 

FIG. ISA is a block diagram of hub node functional modules node in a star 
topology, single chaimel network. 

FIG. 16 is a block diagram of a PIC system with content authorization. 

FIG. 17 is a block diagram of error correction by a buffering component based on 
continuity of TCP sequence numbers. 
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DESCRIPTION OF THE PREFERRED EMBODIMENTS 

Preferred embodiments of the invention will now be described with reference to 
FIGS. 1 to 17. It will be appreciated by those of ordinary skill in the art that the 
description given herein with respect to those figures is for exemplary purposes only and 
5 is not intended in any way to limit the scope of the invention. 

The Passive Intemet Cache has five components, some of which may be distributed 
among hub, intermediate, and/or end-user nodes, as described below. The five 
component are: a monitoring component, an encapsulating component, a buffering 
component, an imencapsulating ("decapsulating^') component, and a global cache 

10 (called a ^PIC Webcache^")- ^ primary monitoring component and an encapsulation 
component are implemented at hub node(s) in all embodiments. A buffering 
component can be implemented at a hub node, intermediate node, and/or end-user node. 
The primary monitoring component at a hub node monitors all IP addresses and TCP 
ports involved in HTTP sessions in use by all nodes using inbound and outbound 

15 channels handled by such hub node, and provides those addresses and ports to the 

various implemented buffering component(s) to enable tracking of all IP addresses and 
TCP ports involved in HTTP sessions; such buffering and tracking enables the 
matching of source sockets and destination sockets used in each of the embodiments. 
The encapsulating component encapsulates HTTP requests in broadcast UDP (or other 

20 connectionless protocol suitable for broadcast or multicast transmission) messages that 
are transmitted firom a hub node through an outbound chatmel and are addressed to all 
remote terminals that can receive that outboimd channel. A secondary monitoring 
component, a decapsulating component, a buffering component, aad a PIC Webcache 
can be implemented at an intermediate node or at an end-user node. The decapsulating 

25 component is interfaced or integml with a buffering component at an intermediate node 
or at an end-user node. An example of an intermediate node is a computer or set-top 
box interfaced with, or integral with, a remote terminal and also interfaced with one or 
more end-user nodes; the interfaces can be a local area network, a system bus, USB, or 
similar connectivity. "Associated with" means two hardware or software devices are 

30 either integral or veiry closely interfaced, as through a system bus, proximate area 
network, USB, high speed local area network, or other close range connectivity, for 
message exchange. 'Interfaced with" means two hardware or software devices are 
closer in distance to each other than to die hub node, normally have a higher datarate 
connection between such devices than to the hub node, and are interconnected through 

35 a local area network, or other medium range connectivity, for message exchange. 

"Buffer" or "buffer memory" means random access memory, disk storage, or equivalent 
read/write technology suitable for the short term storage and retrieval of digital 
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information. 

With reference to FIG. 2B, passive listening and encapsulation is implemented at a 
hub node of a dual channel, star topology network by providing a primary monitoring 
component (201) with unlimited, or ^^promiscuous," access to all HTTP messages 
5 inbound fix)m remote tominals. A hub node in such a star topology network typically 
has a plurality of remote terminals whose inbound channels (each denoted ^'Rcv" in 
FIG. 2B) are received at the hub node, and whose TCP/IP messages are routed to the 
Internet, a private network, and/or a traditional cache. The primary monitoring 
component (201) listens to all inbound HTTP messages in such TCP/IP messages, and 
10 provides HTTP requests to the encapsulation component (202). The encapsulation 
component (202) encapsulates each HTTP request as a broadcast UDP (or other 
connectionless protocol suitable for broadcast or multicast transmission) message and 
provides each such message to the outboimd channel of the hub node (denoted as 
"Xmit"inna2B). 

15 The distribution of the components of a PIC system within a star topology network 

defines the various embodiments of the invention. All embodiments of the PIC system 
require that a remote terminal output all HTTP responses received through the outboimd 
chaimel, not just those HTTP responses with IP addresses assigned to intermediate nodes 
and end-user nodes interfaced with such remote terminal, to each instance of a secondary 

20 monitoring component associated with or interfaced with such remote terminal. Such 
output can be obtained by setting configuration options with some commonly available 
remote terminal or hub node systems. In other instances, existing remote terminal and hub 
node systems may not support reception of HTTP responses by a remote terminal other 
than HTTP responses addressed to a specific remote terminal; in these cases, additional 

25 hardware and/or software components must be added to a remote terminal to provide the . 
ability to receive all HTTP responses in an outboimd channel. Where such additional 
hardware and software components are required to receive all HTTP responses in an 
outbound chaimel, a signal splitter (e.g., a RF- or DF-band splitter for wireless outbound 
channels) and separate receiver/decoder installed at a remote terminal is usually sufficient. 

30 The HTTP requests and HTTP responses transmitted through the commimications 

paths in a PIC system are not handled through a traditional TCP/IP stack and do not 
involve the use of TCP acknowledgements. The buffering component, whether associated 
witii or interfaced with a hub node, an intermediate node, or an end-user node, uses socket- 
matching to pair an HTTP request with the correct HTTP response. With reference to 

35 FIGS. 2 and 2C, in the socket-matching process in a PIC embodiment with buffering and 
PIC Webcache at an end-user node, the buffering component (206) examines the packets 
forwarded by the secondary monitoring component (204). The field sequence observed 
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in HTTP packets is: source IP address (abbreviated "IPs-" in FIG. 2C), destination IP 
address (abbreviated "IPd-" in FIG. 2C), source TCP port number (abbreviated "TCPs-" 
in FIG. 2C), destination TCP port number (abbreviated "TCPd-" in FIG. 2C), and the 
payload (either an HTTP request or aa HTTP response). The secondary monitoring 
5 component (204) forwards each HTTP response (the first packet in packet stream 220, in 
FIG 2C) directly to the buffering component (206) and forwards each UDP packet (the 
second packet in packet stream 220, in FIG 2C) to the decapstdation component (205, in 
FIG. 2), which decapsulates any HTTP request contained in such packet and forwards the 
HTTP request so decapsulated to the buffering component (206). When the buffering 

10 component (206) receives an HTTP response, it examines the source and destination 
sockets, and checks to see if a file (or database record) in buffer memory containing an 
HTTP request has been t^ged with those source and destination sockets. The source and 
destination sockets are reversed in an HTTP request as compared with the corresponding 
HTTP response. The buffering component compensates for the reversal of source and 

1 5 destination sockets when it compares HTTP requests and HTTP responses. If the buffering 
component can match a received HTTP response with a buffered HTTP request, it extracts 
the URL identity from the HTTP request, and creates a file (or database record) for the 
URL on the storage device(s) (21 2, in FIG. 2) used by flie PIC Webcache (207, m FIG. 2) 
as if the PIC Webcache itself had cached the URL. If the buffering component cannot 

20 match the a received HTTP response with a buffered HTTP request, the buffering 
component creates a file (or database record) tagged with the sockets of the HTTP 
response, and stores such file (or database record) in buffer memory. In the case of packet 
stream (220), the HTTP response with addressing of "IPsb, IPda, TCPsb, TCPda,*' in the. 
first portion of packet stream (220) would be buffered and subsequently matched with the- 

25 decapsulated HTTP request with addressing of "EPsa, IPdb, TCPsa, TCPdb," m the second 
portion of packet stream (220). To introduce a second example of socket matching, if the 
. buffering component (206) receives the HTTP request in the first packet in packet stream 
(221) that contains source and destination sockets that the buffering component cannot 
match with a previously buffered HTTP response, the buffering component creates a file 

30 (or database record) tagged with the sockets of that HTTP request, and buffers such file (or 
database record). When the buffering component subsequently receives the HTTP 
response in tiie second portion of packet stream (221), it examines the source and 
destination sockets of that HTTP response, matches those sockets with the previously 
buffered file (or database record) tagged with those source and destination sockets 

35 (compensating for the reversal of source and destination sockets), extracts the URL identity 
from the HTTP request, and creates a file (or database record) for the URL on the storage 
device(s) (212) used by the PIC Webcache (207) as if the PIC Webcache itself had cached 
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the URL. Regardless of whether the HTTP request or the HTTP response is received first, 
to receive and store the URL and the contents of the URL, the PIC system does not obtain 
or use a TCP port number allocated by the end-user node. Thus, even though the browser 
at the end-user node had not previously requested a URL in the PIC Webcache, if the 
browser does request that URL in the future, the contents of the URL will already be in the 
PIC Webcache serving the browser, and vnU be delivered instantly from the PIC Webcache 
to the browser. 

FIG. 2D illustrates the messages exchanged in the operation of a PIC Webcache in 
a PIC embodiment with bufTering and PIC Webcache at an end-user node. In FIG. 2D, an 
unseen remote terminal transmits an HTTP request that is monitored by the primary 
monitoring component at a hub node and handled as described above and as depicted in 
the upper, leftward messs^e flows in FIG. 2D. That HTTP request is also sent in the 
customary maimer from the hub node to a traditional proxy or cache as depicted in the 
upper, rightward message flows in FIG. 2D; if the URL is not found in the traditional 
proxy or cache, the HTTP request is forwarded to the Webserver identified in the URL. 
The traditional proxy or cache, or the Webserver, as the case may be, replies to the HTTP 
request with an HTTP response, which the hub node transmits in the outbound channel as 
described above and as depicted in the lower, leftward message flows in FIG. 2D. 
Socket-matching and storage of the URL and its contents is performed at the end-user 
node, as described above. 

The buffering component in the first embodiment only proceeds with writing the 
contents of the HTTP response in the PIC Webcache under the URL contained in the 
HTTP request if no errors are detected in the HTTP response and HTTP request. The 
buffering component uses the error detection techniques of TCP, such as confirming a 
continuous series of TCP header sequence numbers, to detect errors. If no errors are 
detected, the buffering component writes the contents of the matched HTTP response in 
the PIC Webcache under the URL contained in the matching HTTP request. If errors are 
detected in an HTTP request, the request is discarded, and any HTTP responses that have 
not been matched after the e>q)iration of an operator-controlled time period are also 
discarded. If errors are detected in an HTTP response, and the intermediate node or end- 
user node has access to an inboimd channel, the buffering component can issue an HTTP 
request for a replacement HTTP response. If errors are detected in the HTTP response, and 
the intermediate node or end-user node does not have access to an inbound channel by 
which to issue an HTTP request, the matched but defective HTTP response and matching 
HTTP request are discarded. Normally, any single end-user node would only request a 
small portion of the contents of a PIC Webcache within a given time period, so such 
discarding of corrupted or missing HTTP responses and HTTP requests should have an 
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insignificant impact on the overall performance improvements afforded by use of a PIC 
Webcache. 

The embodiments of the PIC system fall into two categories: embodiments for dual 
channel, star topology networks, and embodiments for single channel, star topology 
5 networks. With each category, there are two sub-categories of embodiments: 
embodiments that perform initial socket-matching at a hub node, and embodiments that 
that do not perform any socket-matching at a hub node. FIGS. 14 and 14A are block 
diagrams of intermediate node, end-user node, and hub node functional modules in a star 
topology, dual channel network. FIGS. IS and ISA are block diagrams of intermediate 

10 node, end-user node, and hub node functional modules in a star topology, single channel 
network. Within each sub-category, there are three basic embodiments that are 
distinguished by whether a buffering component is implemented at an intermediate node 
or at an end-user node, and by whether a PIC Webcache is implemented at an intermediate 
node or at an end-user node, as illustrated in FIGS. 14 and IS for dual channel and single 

15 channel networks, respectively. 

First Embodiment : Buffering and PIC Webcache at end-user node (TR: Socket Matching 
at End-User Node ("EUN")) 

FIG. 2 illustrates the Passive Internet Cache embodiment with socket matching and 
PIC Webcache at an end-user node in a star topology, dual channel network. FIG. 2 A 

20 illustrates the distribution of PIC comi)onents in the first embodiment. FIG. 2B illustrates 
passive listening and encapsulation. FIG. 2C illustrates socket matching. FIG. 2D 
illustrates message exchange using socket matching to store URLs and URL contents in 
a PIC Webcache in the first embodiment. Reference numerals for the first embodiment are 
to Fig. 2 unless otherwise noted. 

25 A first embodiment of the Passive Internet Cache system in a star topology, dual 

channel network implements a primary monitorinjg component (20 1) and an encapsulation 
component (202) at a hub node (203 in Fig. 2A), and a secondary monitoring component 
(204), a decapsulation component (205), a buffering component (206), and a PIC 
Webcache (207) at an end-user node (208 in Fig. 2A) interfaced with a remote terminal 

30 (209). In the context of a star topology, dual channel network, this embodiment of the 
Passive Int^net Cache system provides the lowest cost end-user node for a PIC system. 
Assuming a remote terminal can output all HTTP responses by the use of configuration 
settings, the typical PIC components at the. end-user node are software modules installed 
on an end-user PC and, as such, require no hardware investment to implement. The PIC 

35 Webcache is configured as a proxy server cache and the Web browser on the end-user node 
is configured to use such proxy server cache. The primary monitoring component (201) 
at the hub node (203) monitors all inbound channels transmitted firom all the remote 
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terminals (209, 213) to the hub node (203). The primary monitoring component (201) 
copies all HTTP requests from the monitored inbound channels (2 1 4, 2 1 5), provides each 
HTTP request to the encapsulating component (202), and the encapsulating component 
(202) immediately encapsulates each copied HTTP request in a UDP (or other 
5 connectionless protocol suitable for broadcast or multicast transmission) message. The 
encapsulating component provides each UDP message to the outbound channel (216) for 
transmission in the outbound chaimel using a broadcast IP address and UDP port (or otiier 
suitable protocol, address, and port) monitored by all remote terminals that receive such 
outbound channel and are interfaced with PIC components on end-user nodes. The 

10 secondary monitoring component (204) on the end-user node (208) commimicates through 
a network interface on the end-user node with the remote terminal (209). Using a first 
communications path (210) on the end-user node (208), the secondary monitoring 
component (204) also communicates with the decapsulation component (205), and the 
decapsulation component (205) communicates with the buffering component (206). The 

15 secondary monitoring component (204) copies all of the encapsulated UDP packets from 
the remote terminal (209) to the decapsulation component (205) through a first portion of 
the first communications path (210). When Ifae secondary monitoring component (204) 
on the end-user node provides a UDP packet containing an encapsulated HTTP request to 
the decapsulation component (205), the decapsulation component (205) removes the UDP 

20 encapsulation (""decapsulation"), and forwards each decapsulated HTTP request to the 
buffering component (206) at the end-user node (208 in FIG. 2 A) through a second portion 
of the first communications path (210). The buffering component (206) at the end-user 
node communicates with disk drive(s) (212) or other read/write storage device(s) 
associated wdth the end user node that are used by the PIC Webcache (207) for storage, 

25 The buffering component (206) stores the decapsulated HTTP request in buiBfer memory, 
and opens a file (or database record) tagged with the source socket (source IP address and 
TCP port nimiber) and the destination socket (destination IP address and TCP port number) 
specified in the decapsulated HTTP request The tagged file (or database record) would 
normally be on the storage device(s) used by the PIC Webcache. The tagged file (or 

30 database record) awaits the arrival of the contents of the relevant HTTP response to be 
delivered later fix>m the buffering component. 

Upon receipt at the hub node of an HTTP response, the hub node (203 in FIG. 
2 A) transmits the HTTP response in the outbound broadcast channel (216 in FIG. 2). If 
a browser running on a end-user node interfaced with a remote tenninal originated the 

35 HTTP request that generated the HTTP response, the HTTP response is received in the 
outboxand channel by that remote terminal, forwarded to the PIC Webcache in the 
normal manner, and delivered by the PIC Webcache, operating as a proxy server cache. 
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to the requesting browser. The secondary monitoring component (204) forwards 
through a second communications path (21 1) to the buffering component on the end- 
user node all HTTP packets received by the remote terminal (209), not just those 
packets with an IP destination address of the end-user node (208). If a browser running 
5 on an end-user node interfaced with a remote terminal did not originate the HTTP 
request that generated the HTTP response, the contents of the HTTP response are not 
passed to the browser upon receipt. Rather, the buffering component on the end-user 
node examines the HTTP response to determine the source and destination sockets and 
stores the contents of the HTTP response in the fUe (or database record) previously 

10 tagged with those sockets (the source and destination sockets are reversed in ttie HTTP 
request as compared with the HTTP response). After receiving both the HTTP request 
and the HTTP response, the buffering component at the end-user node can match the 
HTTP request with the correct HTTP response, extract the URL identity from the 
HTTP request, and create a file (or database record) for the URL on the storage 

15 device(s) (212) used by the PIC Webcache as if the PIC Webcache itself had cached the 
URL. To receive and store the HTTP response, the PIC system does not obtain or use a 
TCP port mmiber allocated by the end-user node. If the browser requests that URL in 
the future, the contents of the URL will already be in the PIC Webcache serving the 
browser, and will be delivered instantly from the PIC Webcache to the browser. 

20 In the event the browser running on an end-user node interfaced with a remote 

temiinal did not originate the HTTP request that generated an HTTP response provided by 
the monitoring component at the end-user node to the buffering component at the end-user 
node, and the buffering component at the end-user node has not yet received, via a UDP 
message from the hub node, a copy of the HTTP request that triggered such HTTP 

25 response, the birffering component at the end-user node stores the HTTP response in buffer 
memory, tagged by source socket and destination socket, until the associated HTTP request 
arrives via a UDP message from the hub node. Upon receipt and decapsulation of the 
HTTP request, the buffering component can match the HTTP request with the correct 
HTTP response, extract the URL identity from the HTTP request, and create a file (or 

30 database record) for the URL on the storage device(s) used by die PIC Webcache as if the 
PIC Webcache itself had cached the URL and its contents. 

Second Embodiment : Buffering at intermediate node and PIC Webcache at end-user node 
(TR: Socket Matching at intermediate node ("IN")) 

FIG. 3 illustrates the Passive Internet Cache embodiment with socket matching at 
35 an intermediate node and with PIC Webcache at an end-user node in a star topology, dual 
channel network. FIG. 3 A illustrates the distribution of PIC components in the second 
embodiment. Reference numerals are to FIG. 3 imless otherwise noted. 
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A second embodiment of the Passive Internet Cache system in a star topology, dual 
channel network implements a buffering component (306) at an intermediate node (3 1 7 in 
FIGS. 3 and 3A) and a PIC Webcache (307) at an end-xiser node (308 in FIGS. 3 and 3 A. 
The second embodiment has the advantage of requiring only one instance of a buffering 
5 component interfaced with a given remote terminal; the buffering component serves all 
end-user nodes on one or more local area networks (or other local connectivity) served by 
that remote terminal. This embodiment provides fast end-user response times through the 
use of PIC Webcaches at end-user nodes. Additionally, the use of a separate processor for 
the monitoring and buffering components at an intermediate node pemiits highn 

10 performance memory and a dedicated processor or processors to handle these functions, 
off-loading fliose processing requirements jfrom the end-user nodes. TCP/IP is used in the 
local area network (or other connectiAdty) between the buffering component at the 
interaiediate node and the PIC Webcache in end-user nodes. 

The second embodiment of the Passive Internet Cache system implements a 

15 primary monitoring component (301) and an encapsiilation component (302) at a hub node, 
a secondary monitoring component (304) , a decapsulation component (305), and a 
buffering component (306) at a computer or set-top box ttiat is interfaced with, or is an 
integral part of, a remote terminal (309) and is also interfaced with a local area network 
(318) (or other connectivity) that serves one or more end-user nodes, and the PIC 

20 Webcache (307) component at one or more end-user nodes (308). The end-user nodes may 
also communicate directly with a remote terminal for communications unrelated to the PIC 
system. The PIC Webcache in this embodiment is configured as a proxy server cache and 
the Web browser on the end-user node is configured to use such proxy server cache. The 
primary monitoring component (301) and the encapsulation component (302) of the PIC 

25 system at the hub node (303) fimction as described above. The secondary monitoring 
component (304) at the intermediate node communicates through a network, internal bus 
or other interface with the remote temunal. The secondary monitoring component (304) 
also communicates with the decapsulation component (305), and with the buffering 
component (306), at the intermediate node. The secondary monitoring component (304) 

30 copies firom the remote terminal (309) to the decapsulation component (305) on the 
intermediate node all enc^sulated UDP i>ackets, and to the buffering component (306) on 
the intermediate node, all HTTP packets, received by the remote teimmal, not just those 
packets with an IP destination address of the intermediate node or of end-user nodes served 
by that remote terminal. When the secondary monitoring component (304) receives a 

35 UDP packet containing an encapsulated HTTP request, it provides such packet through a 
first portion of a first communications path (3 1 0) to the decapsulation component (305) at 
the intermediate node. The decapsulation component (305) decapsulates the HTTP 
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request, and forwards each decapsulated HTTP request through a second portion of the first 
communications path (310) to the buflfering component (306) at the intermediate node. 
The buffering component (306) at the intermediate node communicates with disk drive(s) 
or other read/write storage device(s) (3 1 2) associated with each end user node that are used 
5 by one or more end-user nodes' PIC Webcaches (307) for storage. The buffering 
component at the intermediate node stores the decapsulated HTTP request in buffer 
memory, and opens a file (or database record) tagged with the source socket (source IP 
address and TCP port number) and the destination socket (destination IP address and TCP 
port number) specified in the decapsulated HTTP request. The tagged file (or database 

10 record) would normally be on the storage device(s) used by each PIC Webcache inter&ced 
wilh the intermediate node. The tagged file awaits the arrival of the contents of the 
relevant HTTP response to be delivered later by the buffering component. 

Upon receipt at the hub node of an HTTP response, the hub node (303 in FIG 3 A) 
transmits the HTTP response in the outbound broadcast channel (316 in FIG. 3). If a 

1 5 browser running on a end-user node interfaced with a remote terminal originated the HTTP 
request that generated the HTTP response, the HTTP response is received in the outbound 
channel by that remote terminal, forwarded to the PIC Webcache in tiie normal manner, 
and delivered by the PIC Webcache, operating as a proxy server cache, to the requesting 
browser. The secondary monitoring component at the intemiediate node forwards through 

20 a second communications path (3 1 1) every HTTP response in the outbound channel to the 
buffering component running on the intermediate node. If a browser running on an end- 
user node interfaced with a remote terminal did not originate the HTTP request that 
generated the HTTP response, the contents of the HTTP response are not passed to the 
browser upon receipt. Rather, the buffering component on the intermediate node examines - 

25 the HTTP response to determine the source and destination sockets and stores the contents 
of the HTTP response in the file (or database record) previously tagged with those sockets 
(the source and destination sockets are reversed in the HTTP request as compared with the 
HTTP response). After receiving both the HTTP request and the HTTP response, the 
biiffering component at the intermediate node can match the HTTP request with the correct 

30 HTTP response, extract the URL identity from the HTTP request, and create a file (or 
database record) for the URL on the stor^e device(s) used by each PIC Webcache as if 
each PIC Webcache itself had cached the URL. To receive and store the HTTP response, 
the PIC system typically uses a local area network (318) and may use TCP port numbers 
allocated by end-user nodes interfaced with the intermediate node for the purpose of 

35 directiy accessing and updating the PIC Webcache on the disk(s) of the end-user PCs. If 
the browser requests that URL in the future, the contents of the URL will already be in the 
PIC Webcache serving the browser, and will be delivered instantiy from the PIC Webcache 
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to the browser. 

In the event the browser nroning on an end-user node interfaced with an 
intermediate PIC component on a remote terminal did not originate the HTTP request that 
generated an HTTP response provided by the secondary monitoring component at the 
5 intermediate node to the buffering component at the intermediate node, and the buffering 
component at the intermediate node has not yet received via an encapsulated UDP message 
from the hub node containing a copy of the HTTP request that triggered such HTTP 
response, the buffering component at the intermediate node stores the HTTP response in 
buffer memory, tagged by source socket and destination socket, until the correct 

10 (matchable sockets) HTTP request arrives via an encapsulated UDP message from the hub 
node. Upon receipt and decapsulation of the HTTP request, the buffering component can 
match the HTTP request with the correct HTTP response, extract the URL identity from 
the HTTP request, and create a file (or database record) for the .URL on the storage 
device(s) used by a PIC Webcache as if the PIC Webcache itself had cached the URL and 

15 its contents. 

Third Embodiment : Buffering and PIC Webcache at intermediate node (TR: Socket 
Matching at IN) 

FIG. 4 illustrates the Passive Internet Cache embodiment with socket matching and 
PIC Webcache at an intermediate node in a star topology, dual channel network. FIG. 4A 

20 illustrates the distribution of PIC components in the third embodiment. Reference 
numerals are to FIG. 4 unless otherwise noted. 

A third embodiment of the Passive Internet Cache system in a star topology, dual 
channel network implements a buffering component (406) and a PIC Webcache (407) an 
intermediate node (417). This embodiment has the advantage of requiring only one 

25 instance of the secondary monitoring component, buffering component, and PIC Webcache 
to serve all end-user nodes on one or more local area networks (418) (or other local 
connectivity) interfaced with the intermediate node, and providing improved response time 
without the expense of have end-user nodes equipped witii caching devices. Additionally, 
high performance memory, storage, and dedicated processor(s) can provide performance 

30 improvements by off-loading processing and storage requirements from the end-user 
nodes. Such a configuration is well-suited to a residential set-top box used as an 
intermediate node, with home PCs, appliances, security, and environmental systems as 
end-user nodes. TCP/IP is used in the local area network (or other connectivity) between 
the intermediate node and the end-user nodes. 

35 The third embodiment of the Passive Internet Cache system implements a primary 

monitoring (401) and an encapsulation component (402) at a hub node, a secondary 
monitoring component (404), decapsulation component (405), buffering component (406), 

22 



wo 01/88761 



PCT/USOl/15575 



and PIC Webcache (407) at a computer or set-top box that is interfaced with, or is an 
integral part o:^ a remote terminal (409) and is also interfaced with a local area network 
(4 1 8) (or other connectivity) that serves one or more end-user nodes. The end-user nodes 
may also communicate directly with a remote terminal for communications unrelated to 
5 the PIC system. The PIC Webcache in this embodiment may be configured as a proxy 
server cache (i.e., browsers configured to use a TCP port for HTTP that is uniquely 
allocated to the PIC Webcache) or as a caching appliance (i.e., browsers need not be 
configured to use a TCP port for HTTP that is uniquely allocated to the PIC Webcache, 
and would normally use well-known TCP port 80). The Web browser on the end-user 

1 0 node must be configured for proxy server cache if the proxy configuration is implemented. 
If the PIC Webcache is configured as a caching ^pliance, it is not necessary to configure 
browsers on end-user nodes to use a caching appliance, since using well-known TCP port 
80 in the destination socket directs HTTP requests through the caching appliance. The 
primary monitoring component (401) and the encapsulation component (402) of the PIC 

15 system at the hub node function (403 in FIG. 4 A) as described for the first and second 
embodiments. In addition, the secondary monitoring component (404), and the 
decapsulation component (405), at the intermediate node communicate and function as 
described in the second embodiment. The buffering component (406) at the intermediate 
node communicates with disk drive(s) (412) or other read/write storage device(s) 

20 associated with the intermediate node that are used by one or more PIC Webcaches (407) 
at the intermediate node for storage. The buffering component at the intermediate node 
stores the decapsulated HTTP request in buffer memory, and opens a file (or database- 
record) tagged with the source socket (source IP address and TCP port number) and the 
destination socket (destination IP address and TCP port nxmiber) specified in the * 

25 decapsulated HTTP request. Multiple PIC Webcaches may be associated with the 
intermediate node to enable load-sharing or redundancy. The tagged file (or database 
record) would normally be pn the storage device(s) used by the PIC Webcache at the 
intermediate node. The tagged file (or database record) awaits the arrival of the contents 
of the relevant HTTP response to be delivered later by the buffering component 

30 Upon receipt at the hub node of an HTTP response, the hub node (403 in FIG 4A) 

transmits the HTTP response in the outbound broadcast chaimel (416 in FIG. 4). If a 
browser running on a end-user node interfaced through a PIC-equipped intermediate node 
to a remote terminal originated the HTTP request that generated the HTTP response, the 
HTTP response is received in the outboimd channel by that remote terminal, forwarded to 

35 the PIC Webcache in the normal manner, and delivered by the PIC Webcache, operating 
either as a proxy server cache or as a caching appliance, to the requesting browser. The 
secondary monitoring component at the intermediate node forwards through a second 
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communications path (41 1) every HTTP response in the outbo\md channel to the bufifering 
component running on the mtermediate node. If a browser running on an end-user node 
interfaced through a PIC-equipped intermediate node to a remote terminal did not originate 
the HTTP request that generated the HTTP response, the contents of the HTTP response 
are not passed to the browser upon receipt. Rather, the buffering component on the 
intermediate node examines the HTTP response to determine the source and destination 
sockets and stores the contents of the HTTP response in the file (or database record) 
previously tagged with those sockets (the source and destination sockets are reversed in 
the HTTP request as compared with the HTTP response). After receiving both the HTTP 
request and tiie HTTP response, the buffering component at the intermediate node can 
match the HTTP request with the correct HTTP response, extract the URL identity from 
the HTTP request, and create a file (or database record) for the URL on the storage 
device(s) used by the PIC Webcache(s) at the intermediate node as if the relevant PIC 
Webcache itself had cached the URL. To receive and store the HTTP response, the PIC 
system does not obtain or use a TCP port number allocated by end-user nodes interfaced 
with the intermediate node. If a browser on an end-user node requests that URL in the 
future, the contents of the URL will already be in the PIC Webcache, and will be delivered 
from the PIC Webcache to the browser. 

In the event the browser running on an end-user node interfaced with a remote 
terminal did not originate the HTTP request that generated an HTTP response provided by 
the secondary monitoring component at the intermediate node to the buffering component 
at the intermediate node, and the buffering component at the intermediate node has not yet 
received, via an encapsulated UDP message from the hub node, a copy of the HTTP 
request that triggered such HTTP response, the buffering component at the intermediate 
node stores the HTTP response in buffer memory, tagged by source socket and destination 
socket, until the correct (matchable sockets) HTTP request arrives via an encapsulated 
UDP message from the hub node. Upon receipt and decapsulation of the HTTP request, 
the buffering component can match the HTTP request with the correct HTTP response, 
extract the URL identity from the HTTP request, and create a file (or database record) for 
the URL on the storage device(s) used by the PIC Webcache(s) on the intermediate node 
as if the relevant PIC Webcache itself had cached Hie URL and its contents. 
Fourth Embodiment : Split Buffering (hub and end-user nodes) and PIC Webcache at end- 
user node (TR: Socket Matching at hub node ("HN'O) 

FIG. 5 illustrates the Passive Internet Cache embodiment with socket matching at 
the hub node and with secondary buffering and PIC Webcache at an end-user node in a star 
topology, dual channel network. FIG. 5 A illustrates the distribution of PIC components 
in the fourth embodiment Reference mmierals are to FIG. 5 unless otherwise noted. 
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A foiirth embodiment of the Passive Intemet Cache system in a star topology, dual 
channel network implements a primary monitoring component (501), an encapsulation 
component (5 02), and a primary buffering component (5 1 9) at a hub node, an initial socket 
matching function in the primary buffering component (519) at the hub node, and a 
5 secondary monitoring component (504), a secondary buffering component (506), a 
decapsulation component (505), and a PIC Webcache (507) at an end-user node (508 in 
FIG. 5 A). In the context of a star topology, dual channel network witii a large number of 
remote terminals, the use of a primary buffering component at the hub node permits a 
smaller buffer memory, lower performance storage, and a lower performance processor to 

10 be used by the secondary buffering component at the end-user node. Assuming a remote 
terminal can output all HTTP responses by the use of configuration settings, the typical 
PIC components at the end user node are software modules installed on an end-user PC 
and, as such, require no hardware investment to implement. The PIC Webcache is 
configured as a proxy server cache and the Web browser on the end-user computer is 

15 configured to use such proxy server cache. The primary monitoring component (501) at 
the hub node monitors all inbound channels transmitted from all the remote terminals (509, 
5 13) to the hub node . The primary monitoring component (50 1) copies all HTTP requests 
from the monitored inbound channels (5 14, 5 1 5), and forwards each HTTP request to the 
encapsulation component (502). The encapsulation component creates a UDP packet 

20 containing the HTTP request using a broadcast IP address and port as described above, and 
forwards the encapsulated packet to the primary buffering component (519) at flie hub 
node. The primary buffering component (519) stores the encapsulated HTTP request in 
buffer memory, tagged with the source socket (source IP address and TCP port number) 
and the destination socket (destination IP address and TCP port number) specified in the 

25 HTTP request. The primary buffering component at the hub node examines the source and 
destination sockets in the IP packet containing the HTTP response and matches them with 
the destination and source sockets in the appropriate previously UDP-encapsulated IP 
packet containing the HTTP request. Upon receipt at the hub node of an HTTP response, 
the primary monitoring component (501) provides the HTTP response to the primary 

30 buffering component (519) at the hub node. The HTTP response is not immediately 
broadcast by the hub node in the outboimd channel. The primary buffering component 
(519) at the hub node examines the source and destination sockets in the IP packet 
containing the HTTP response and matches them with the destination and source sockets 
in the corresponding, previously UDP-encapsulated IP packet containing the HTTP request 

35 (the source and destination sockets are reversed in the HTTP request as compared with the 
HTTP response). The primary buffering component (519), soon after providing the 
encapsulated HTTP request to the outboimd channel (516), provides the corresi)onding 
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HTTP response to the outbound channel (516) for transmission to the remote terminals 
(509,513). 

The secondary monitoring component (504) at the end-user node (508, in FIG. 5 A) 
communicates through a network interface on the end-user node with the remote terminal 

(509) , The secondary monitoring component (504) also communicates through a first 
conununications path (5 1 0) with the decapsulation component (505), and thence with the 
secondary buffering component (506), at the end-user node. The secondary monitoring 
component (504) copies fix>m the remote terminal through the first communications path 

(5 10) to the decapsulation component (505) on the end-user node all encapsulated UDP 
packets, and through a second communications path (51 1) to the secondary buffering 
component on the end-user node all HTTP packets, received by the remote terminal, not 
just those packets with an IP destination address of the end-user node. When the 
secondary monitoring component (504) on the end-xiser node receives a UDP packet 
containing an encapsulated HTTP request, it provides through a first portion of the first 
commimications path (510) such packet to the decapsulation component. The 
decapsulation component removes the UDP encapsulation ("decapsulation*'), and forwards 
through a second portion of the first communications path (5 1 0) each decapsulated HTTP 
request to the buffering component at the end-user node. Hie buffering component at the 
end-user node communicates with disk drive(s) or other read/write storage device(s) 
associated with the end user node that are used by the PIC Webcache for storage. The 
buffering component stores the decapsulated HTTP request in buffer memory, and opens 
a file (or database record) t^ged with the source socket (source IP address and TCP port 
number) and the destination socket (destination IP address and TCP port number) specified 
in the decapsulated HTTP request. The tagged file (or database record) would normally 
be on the storage device(s) used by the PIC Webcache. The tagged file (or database 
record) awaits the arrival of the contents of the relevant HTTP response fi:om the buffering 
component. 

If a browser running on a end-user node interfaced with a remote terminal 
originated the HTTP request that generated the HTTP response, the HTTP response is 
received in the outbound channel by that remote terminal, forwarded to the PIC Webcache 
in the normal manner, and delivered by the PIC Webcache, operating as a proxy server 
cache, to the requesting browser. The secondary monitoring component (504) at the end- 
user node also forwards through the second communications path (511) every HTTP 
response in the outbound chaimel to the secondary buffering component (506) running on 
the end-user node. If a browser running on an end-user node interfaced with a remote 
terminal did not originate the HTTP request that generated the HTTP response, the 
contents of the HTTP response are not passed to the browser upon receipt. Rather, the 
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secondary buffering component on the end-user node examines the HTTP response to 
determine the source and destination sockets and stores the contents of the HTTP response 
in the file (or database record) previously tagged with those sockets (the source and 
destination sockets are reversed in the HTTP request as compared with the HTTP 
5 response). After receiving both the HTTP request and the HTTP response, the secondary 
buffering component at the end-user node can match the HTTP request with the correct 
HTTP response, extract the URL identity from the HTTP request, and create a file (or 
database record) for the URL on the storage device(s) (512) used by the PIC Webcache 
(507) as if the PIC Webcache itself had cached the URL. To receive and store the HTTP 
10 response, the PIC system does not obtain or use a TCP port number allocated by the end- 
user node. If the browser requests fliat URL in the future, the contents of the URL will 
already be in the PIC Webcache serving the browser, and will be delivered instantly from 
the PIC Webcache to the browser. 

Fifth Embodiment : Split Buffering (hub node and intermediate node) and PIC Webcache 

15 at end-user node (TR: Socket Matching at HN) 

FIG. 6 illustrates the Passive Intemet Cache embodiment with socket matching at 
the hub node, with secondary buffering at an intermediate node, and with PIC Webcache 
at an end-user node in a star topology, dual chaimel network. FIG. 6A illustrates the 
distribution of PIC components in the fifth embodiment. Reference numerals are to FIG. 

20 6 unless otherwise noted. 

A fifth embodiment of the Passive Intemet Cache system in a star topology, dual 
channel network implements a primary monitoring component (601), an encapsulation 
component (602), and a primary buffering component (619) at the hub node, an initial 
socket matching function in the primary buffering component at the hub node, and a 

25 secondary monitoring component (604), a secondary buffering component (606), and a 
decapsulation component (605) at an intermediate node, and a PIC Webcache (607) at an 
end-user node. In the context of a star topology, dual channel network with a large number 
of remote terminals, the use of a primary buffering component at the hub node permits 
smaller buffer memory and lower perforaiance storage and processor to be used by the 

30 secondary buffering component at the intermediate node. The PIC Webcache is 
configured as a proxy server cache and the Web browser on the end*user computer is 
configured to use such proxy server cache. The primary monitoring component at the hub 
node monitors all inbound channels transmitted firom all the remote terminals to the hub 
node. The primary monitoring component (601) copies all HTTP requests fix)m the 

35 monitored inbound chaimels, and provides each HTTP request to the encapsulation 
component (602) where, as in the fourth embodiment, each HTTP request is encapsulated 
in a UDP packet with a broadcast IP address and port and is then forwarded to the primary 

27 



wo 01/88761 



PCT/USOl/15575 



buffering component (6 1 9) at the hub node. The primary buffering component (6 1 9) stores 
the encapsulated HTTP request in buffer memory at the hub node, tagged with the soxirce 
socket (soxirce IP address and TCP port number) and the destination socket (destination IP 
address and TCP port number) specified in the HTTP request. Upon receipt at the hub 
5 node of an HTTP response, the primary monitoring component (60 1 ) provides the HTTP 
response to the primary buffering component (619) at the hub node. The HTTP 
response is not immediately broadcast by the hub node in the outbound channel. The 
primary buffering component (619) at the hub node examines the source and destination 
sockets in the IP packet containing the HTTP response and matches them with the 

10 destination and source sockets in the associated, previously UDP-encapsulated IP packet 
containing the HTTP request (the source and destination sockets are reversed in the HTTP 
request as compared with the HTTP response). After receiving both the HTTP request and 
the HTTP response, the primary buffering component (6 1 9) provides the HTTP request to 
the outbound channel (616) for transmission in the outboxmd channel using a broadcast BP 

15 address and UDP port (or other suitable protocol, address, and port) monitored by all 
remote terminals that receive such outbound channel and are interfaced with local PIC 
components. The primary bxiflfering component (619), soon after providing the 
encapsulated HTTP request to the outbound chaimel (616), provides the corresponding 
HTTP response to the outbound channel (616) for transmission to the remote terminals 

20 (609, 613). 

The secondary monitoring component (604) at the intermediate node (61 7 in FIG. 
6 A) communicates through a network interface on the intermediate node with the remote 
terminal. The secondary monitoring component (604) also communicates with the 
decapsulation component (605), and with the secondary buffering component (606), at the 

25 intermediate node. The secondary monitoring component (604) copies from the remote 
terminal (603) and forwards through a first portion of a first commimications path (610) 
to the decapsulation component (605) on the intermediate node all encapsulated UDP 
packets, and through a second commimications path (61 1) to the secondary buffering 
component on the intermediate node all HTTP packets, received by the remote terminal, 

30 not just those packets with an IP destination address of the intermediate node or of end- 
user nodes served by that remote terminal. When the secondary monitoring component 
(604) on the intermediate node receives a UDP packet containing an enc^sulated HTTP 
request, it provides such packet to the decapsulation component tiirough the first portion 
of the first commimications path (610). The decapsulation component removes the UDP 

35 encapsulation ("decapsulation"), and forwards through a second portion of the first 
communications path (611) each decapsulated HTTP request to the secondary buffering 
component (606) at the intermediate node. The secondary buffering component (606) at 
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the intennediate node communicates with disk drive(s) (612) or other read/write storage 
device(s) associated with each end user node that are used by one or more end-user nodes' 
PIC Webcaches for storage. The secondary buflfering component stores the decapsulated 
HTTP request in buffer memory, and opens a file (or database record) tagged with the 
5 source socket (source IP address and TCP port number) and the destination socket 
(destination IP address and TCP port number) specified in the decapsulated HTTP request. 
The tagged file (or database record) would normally be on the storage device(s) used by 
each PIC Webcache interfaced with flie intennediate node. The tagged file (or database 
record) awaits the arrival of the contents of the relevant HTTP response firom the buffering 
10 component. 

If a browser running on a end-user node interfaced with a remote terminal 
originated flie HTTP request that generated the HTTP response, the HTTP response is 
received in the outbound channel by that remote terminal, forwarded to each PIC 
Webcache in the normal manner, and delivered by the PIC Webcache associated with an 

15 end-user node, operating as a proxy server cache, to the requesting browser. The 
secondary monitoring component (604) at the intermediate node also forwards through the 
second commimications path (61 1) every HTTP response in the outbound channel to the 
secondary buffering component (606) running on the intermediate node. If a browser 
running on an end-user node interfaced with a remote terminal did not originate the HTTP 

20 request that generated the HTTP response, the contents of the HTTP response are not 
passed to the broMrser upon receipt. Rather, the secondary buffering component on the 
intermediate node examines the HTTP response to detemiine the source and destination 
sockets and stores the contents of the HTTP response in the file (or database record) 
previously tagged with those sockets (the source and destination sockets are reversed in 

25 the HTTP request as compared with the HTTP response). After receiving both the HTTP 
request and the HTTP response, the second^ buffering component at the, intennediate 
node can match the HTTP request with the correct HTTP response; extract the URL 
identity fi-om the HTTP request, and create a file (or database record) for the URL on the 
storage device(s) used by each PIC Webcache as if each PIC Webcache itself had cached 

30 the URL. To receive and store the HTTP response, the PIC system typically uses a local 
area network (618) and may use a TCP port number allocated by an end-user node for the 
purpose of directly accessing the disk area of the PIC Webcache on the end-user node. If 
a browser requests that URL in the fiiture, the contents of the URL will already be in tiie 
PIC Webcache serving the browser, and will be delivered instantly fix>m the PIC Webcache 

35 to the browser. 

Sixth Embodiment : Split Buffering (hub node and intermediate node) and PIC Webcache 
at intennediate node (TR: Socket Matching at HN) 
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FIG. 7 illxistrates the Passive Internet Cache embodiment with socket matching at 
the hub node and with PIC Webcache at an intemiediate node in a star topology, dual 
channel network. FIG. 7A illustrates the distribution of PIC components in the sixth 
embodiment. Reference numerals are to FIG. 7 imless otherwise noted. 

A sixth embodiment of the Passive Intemet Cache system in a star topology, dual 
chaimel network implements a primary monitoring component (701), an encapsiilation 
component (702), and a primary buffering component (7 1 9) at a hub node, an initial socket 
matching function in the primary buffering component (719) at the hub node, and a 
secondary monitoring component (704), a secondary buffering component (706), a 
decapsulation component (705), and a PIC Webcache (707) at an intermediate node (717 
in FIG. 7A). In the context of a star topology, dual channel network with a large number 
of remote terminals, the use of a primary buffering component at the hub node permits 
smaller buffer memory and lower performance storage and processor to be used by the 
secondary buffering component at the intermediate node. This embodiment has the 
advantage of requiring only one instance of the secondary monitoring component, 
buffering component, and PIC Webcache to serve all end-user nodes on one or more local 
area networks (or other local connectivity) interfaced with the intermediate node, and 
providing improved response time without the expense of have end-user nodes equipped 
with caching devices. Additionally, high performance memory, storage, and dedicated 
processor can provide performance improvements by off-loading processing and storage 
requirements from the end-user nodes. The end-user nodes may also communicate directly 
with a remote terminal for communications unrelated to the PIC system. The PIC 
Webcache in this embodiment may be configured as a proxy server cache (i.e., browsers 
configured to use a TCP port for HTTP that is uniquely allocated to the PIC Webcache) 
or as a caching appliance (i.e., browsers need not be configured to use a TCP port for 
HTTP that is vmiquely allocated to the PIC Webcache, and would normally use well- 
known TCP port 80). The Web browser on the end-user node must be configured for 
proxy server cache if the proxy configuration is implemented. If the PIC Webcache is 
configured as a caching appliance, it is not necessary to configure browsers on end-user 
nodes to use the caching appliance, since using well-known TCP port 80 in the destination 
socket directs HTTP requests through the caching appUance. 

The primary monitoring component (70 1 ), the primary buffering component (719), 
and the encapsulation component (702) of the PIC system at the hub node fimction as 
described above for the fourth and fifth embodiments. In addition, the secondary 
monitoring component (704), the decapsulation component (705), first communications 
path (710), and second communications path (71 1) at the intermediate node function as 
described above for the fifth embodiment. In the sixth embodiment, the secondary 
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bufTering component (706) at the intetmediate node communicates with diskdrive(s) (712) 
or other read/write storage device(s) located at the intermediate node that are used by one 
or more PIC Webcaches at the intermediate node for storage. The secondary buffering 
component (706) at the intermediate node stores the decapsulated HTTP request in buffer 
5 memory, and opens a file (or database record) tagged with the source socket (source IP 
address and TCP port number) and the destination socket (destination IP address and TCP 
port number) specified in the decapsulated HTTP request. The tagged file (or database 
record) would normally be on the storage device(s) used by a given PIC Webcache at the 
intermediate node. Multiple PIC Webcaches may be associated with the intermediate node 

1 0 to enable load-sharing or redundancy. The tagged file awaits the arrival of the contents of 
the relevant HTTP response &om the buffering component. 

If a browser running on a end-user node inter&ced with a remote terminal 
originated the HTTP request that generated the HTTP response, the HTTP response is 
received in the outbound chamiel by that remote teraiinal, forwarded to the relevant PIC 

15 Webcache in the normal manner, and delivered by the PIC Webcache, operating either as 
a proxy server cache or as a cascaded caching appliance, to the requesting browser. The 
secondary monitoring component at the intermediate node forwards every HTTP response' 
in the outboimd channel to the secondary buffering component running on the intermediate 
node. If a browser running on an end-user node interfaced with a remote terminal did not 

20 originate the HTTP request that generated the HTTP response, the contents of the HTTP 
response are not passed to the browser upon receipt. Rather, the secondary buffering 
component on the intermediate node examines the HTTP response to determine the soiirce 
and destination sockets and stores flie contents of the HTTP response in the file (or 
database record) previously tagged with those sockets (the source and destination sockets 

25 are reversed in the HTTP request as compared with the HTTP response). After receiving 
both the HTTP request and the HTTP response, the secondary buffering component at the 
intermediate node can match the HTTP request with the correct HTTP response, extract 
the URL identity from the HTTP request, and create a file (or database record) for the URL 
on the storage device(s) used by one or more PIC Webcaches at the intermediate node as 

30 if the PIC Webcache itself had cached the URL and its contents. To receive and store the 
HTTP response, the PIC system does not obtain or use a TCP port number allocated by 
end-user nodes interfaced with the intemiediate node. If a browser on an end-user node 
requests that URL in the future, flie contents of the URL will already be in the relevant PIC 
Webcache, and will be delivered firom the PIC Webcache to the browser. 

35 Seventh Embodiment : Buffering and PIC Webcache at ^d-user node (RO: Socket 
Matching at EUN) 

FIG. 8 illustrates the Passive Internet Cache embodiment with socket matching and 
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PIC Webcache at an end-user node in a star topology, single chaimel network. FIG. 8A 
illustrates the distribution of PIC components in the seventh embodiment. Reference 
numerals are to FIG. 8 unless otherwise noted. 

A seventh embodiment of the PIC system is stmcturally and functionally identical 
the first embodiment, except the remote terminal is receive only and cannot initiate HTTP 
requests. The inability to initiate HTTP requests, or other return channel messages, does 
not prevent or impair the operation of the components of the PIC system. The PIC 
Webcache built at an end-user node reflects the HTTP requests initiated by other end-user 
nodes that have an inbound channel. 

Eighth Ern hndiment! Buffering at intermediate node and PIC Webcache at end-user node 
(RO: Socket Matching at IN) 

FIG. 9 illustrates the Passive Internet Cache embodiment with socket matching at 
an intermediate node and with PIC Webcache at an end-user node in a star topology, single 
channel network. FIG. 9A illustrates the distribution of PIC components in the eighth 
embodiment. Reference numerals are to FIG. 9 unless otherwise noted. 

An eighth embodiment of the PIC system is structurally and functionally identical 
the second embodiment, except the remote temiinal is receive only and cannot initiate 
HTTP requests. The inability to initiate HTTP requests, or other retum channel messages, 
does not prevent or impair the operation of the components of the PIC system. The PIC 
Webcache built at an end-user node reflects the HTTP requests initiated by other end-user 
nodes that have an inbound channel. 

Ninth Embodiment : Buffering and PIC Webcache at intermediate node (RO: Socket 
Matching at IN) 

FIG. 10 illustrates the Passive Intemet Cache embodiment with socket matching 
and PIC Webcache at an intermediate node in a star topology, single channel network. 
FIG. lOA illustrates the distribution of PIC components in the ninth embodiment 
Reference numerals are to FIG. 10 unless otherwise noted. 

A ninth embodiment of the PIC system is stmcturally and fimctioneilly identical the 
third embodiment, except the remote terminal is receive only and cannot imtiate HTTP 
requests. The inability to initiate HTTP requests, or other retum channel messages, does 
not prevent or impair the operation of the components of the PIC system. The PIC 
Webcache built at an intermediate node reflects the HTTP requests initiated by other end- 
user nodes that have an inbound channel. 

Tenth Embodiment : Split Buffering (hub and end-user nodes) and PIC Webcache at end- 
user node (RO: Socket Matching at HN) 

FIG. 1 1 illustrates the Passive Intemet Cache embodiment with socket matching 
at the hub node and with secondary buffering and PIC Webcache at an end-user node in 
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a star topology, single channel network. FIG. 11 A illustrates the distribution of PIC 
components in the tenth embodiment. Reference nimierals are to FIG. 1 1 unless otherwise 
noted. 

A tenth embodiment of the PIC system is structurally and functionally identical the 
5 fourth embodiment, except the remote terminal is receive only and caimot initiate HTTP 
requests. The inability to initiate HTTP requests, or other retum channel messages, does 
not prevent or impair the operation of the components of the PIC system. The PIC 
Webcache built at an end-user node reflects the HTTP requests initiated by other end-user 
nodes that have an inbound channel. 
10 Eleventh Rmhndiment : Split Buffering (hub node and intemiediate node) and PIC 
Webcache at end-user node (RO: Socket Matching at HN) 

FIG. 12 illustrates the Passive Internet Cache embodiment with socket matching 
at the hub node, with secondary buffering at an intermediate node, and with PIC 
Webcache at an end-viser node in a star topology, single channel network. FIG. 12 A 
15 illustrates the distribution of PIC components in the eleventh embodiment. Reference 
numerals are to FIG. 12 unless otherwise noted. 

An eleventh embodiment of the PIC system is structurally and functionally 
identical the fifth embodiment, except the remote terminal is receive only and cannot 
initiate HTTP requests. The inability to initiate HTTP requests, or other retum channel 
20 messages, does not prevent or impair the operation of the components of the PIC system. 
The PIC Webcache built at an end-user node reflects the HTTP requests initiated by other 
end-user nodes that have an inbound channel. 

Twelfth Embodiment : Split Buffering (hub node and intermediate node) and PIC 
Webcache at intermediate node (RO: Socket Matching at HN) 
25 FIG. 13 illustrates the Passive Internet Cache embodiment with socket matching 

at the hub node and with secondary buflfering and PIC Webcache and at an intermediate 
node in a star topology, single channel network. FIG. 13A illustrates the distribution of 
PIC components in the twelfth embodiment Reference numerals are to FIG. 13 unless 
otherwise noted. 

30 A twelfth embodiment of the PIC system is structurally and functionally identical 

the sixth embodiment, except the remote temiinal is receive only and cannot initiate HTTP 
requests. The inability to initiate HTTP requests, or other retum channel messages, does 
not prevent or impair Ihe operation of the components of the PIC system. The PIC 
Webcache built at an intermediate node reflects the HTTP requests initiated by other end- 

35 user nodes that have an inboimd channel. 

For simplicity, in the embodiments that do not allocate TCP ports, if a browser 
running on an end-user node interfaced with a remote terminal originated the HTTP 
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request that generated a given HTTP response, a PIC system would normally be configured 
so that the same HTTP request after being decapsulated from a UDP message, after receipt 
of the socket-matched HTTP response, causes an overwrite of the URL in the PIC 
Webcache that was already written in response to the HTTP response addressed directly 
5 to that end-user node's IP address and TCP port number (rather than through the PIC 
system). Such an implementation is said to have ^'exhaustive writing*' of HTTP requests 
received by the PIC buffering component through UDP messages (i.e., does not need to 
recognize local addresses before writing the URL processed through the PIC system). 
Alternatively, a PIC buffering component on an end-user node can be designed for 

10 "selective writing" so that it does not write any HTTP request received by the PIC 
monitoring component through UDP messages to the PIC Webcache if the destination IP 
address of the HTTP response is that of the node on which the PIC Webcache is running. 
In case of "selective writing", the normal dialog of an HTTP request and an HTTP 
response will cause the requested URL to be written to the browser or cache that originated 

15 the HTTP request. 

If the necessary decryption keys are available, a PIC system can work with 
encrypted HTTP messages. If encrypted HTTP messages are exchanged, and the necessary 
decryption key is not available to a PIC system, the PIC system is unable to use (or 
possibly detect) HTTP messages that are encrypted. In all embodiments of the PIC system, 

20 encrypted payloads are simply handled as any other message, i.e. cached in the encrypted 
form if TCP/IP header information is available and HTTP commands are decipherable, or 
discarded if not. Independently of the PIC system components, encrypted HTTP messages 
are processed in a normal manner, so that a browser sending an encrypted HTTP request 
can still receive an encrypted HTTP response. 

25 The retum chaimel from a hub node through one or more monitoring components, 

encapsulating component, decapsulating component, one or more buffering components, 
to each PIC Webcache can also carry UDP messages that can be used to control HTTP 
content cached by a PIC Webcache based on the URL in an HTTP request or the source 
IP address of an HTTP response. Such access control can be used to permit or prevent 

30 caching of URLs and their content in a PIC Webcache in order to implement a subsoiption 
authorization system, or simply to block content from objectionable network domains, 
hosts, etc. With reference to FIG. 16, implementation of access control using a PIC 
system requires a content authorization program and database associated with or inter&ced 
with the hub node (1 620), preparation of content authorization messages addressed to one 

35 or more buffering components associated with remote terminals by the content 
authorization program, encapsulation of the authorization control messages by the 
encapsulating component (1602) at a hub node, transmission of the encapsulated 
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authorization control messages in the outbound channel (1616), delivery of the 
decapsulated authorization control messages to the each buffering component in the same 
manner as delivery of decapsulated HTTP requests as described above, and execution of 
the authorization control message by an intermediate node content authorization 
5 component (1621) associated with a buffering component (1606) and/or by an end-user 
node content authorization component (1622) associated with a PIC Webcache (1607). 
The authorization control message determines v/bat URLs are cached in a given PIC 
Webcaches; messages exchanged between the buffering component (1606) and a given 
intermediate node or end-user node content authorization component determine what URLs 

10 are blocked j&om caching. Content authorization components (1621, 1622) associated with 
or interfaced with a remote terminal prevent a PIC Webcache from caching a URL or 
source IP address that is specified as unauthorized ("blocked") for a given PIG Webcache, 
Content authorization through a content authorization program and database is known in 
the art, but its use in conjunction with a PIC system is novel. A content authorization 

15 component at different end-user nodes can be used to create end-user PIC Webcaches with 
different content, but associated with a single mtermediate node (1617) and intermediate 
node content authorization component (1621). By using a content authorization 
component (1621) at an intermediate node (1617), an additional point of content control 
is introduced. Content authorization at an intermediate node PIC Webcache (not 

20 illustrated) can be implemented in networks that have some end-user nodes equipped with 
PIC Webcaches and some fliat are not equipped with PIC Webcaches. Different end-user 
nodes can also be assigned to use different PIC Webcaches, and fliereby have access to 
different content. 

The buffering component at an intermediate node or at an end-user node can 
25 contain a program that monitors whether the payload of an HTTP request or HTTP 
response has errors based on common error checking methods, such as packet sequence 
number continuity. A given HTTP message may require multiple TCP/IP packets for 
transmission. With reference to FIG. 17, TCP inserts a sequence number into each packet 
used to transmit a given HTTP message. For a given HTTP response provided to a PIC 
30 buffering component associated with or interfaced with a remote terminal, only one 
payload of a packet with a given TCP sequence number is needed. If a packet stream for 
a given HTTP request contains more than one packet with the same TCP sequence number 
(upper portion of FIG. 1 7), the buffering component discards packets with duplicate TCP 
sequence numbers. Sucherror checking is without the buffering component's participation 
35 in normal TCP/IP protocol handshakes. By reference to the lower portion of FIG. 17, a 
PIC buffering component associated with or interfaced with a remote terminal can be 
configured to discard HTTP messages determined by the buffering component to have 
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missing TCP sequence numbers. If the remote terminal associated with or interfaced with 
a buffering component has inbound channel capability, and the buffering component 
determines that an HTTP response has a corrupted pay load, the buffering component can 
(optionally) use the URL in the decapsulated HTTP request to generate an HTTP request 
5 from flie end-user node (using normal TCP/IP procedures) for flie URL at issue, and obtain 
another HTTP response from the relevant Webserver. 

Taking an "end to end" perspective of the handling of UDP messages and HTTP 
responses by PIC components, in PIC embodiments without socket-matching at a hub 
node, for UDP messages, a first end-to-end communications path exists thiough a 

10 primary monitoring component and encapsulating component at a hub node, then 
through an outbound channel from the hub node, then through a remote terminal to a 
secondary monitoring component and decapsulating component to a buffering 
component; for HTTP responses, a second end-to-end communications path exists from 
extemal server computers or traditional caches through the outboimd chaimel of the hub 

15 node, then through the remote terminal to the secondary monitoring component, and 
then to the buffering component. In PIC embodiments with socket-matching at a hub 
node, for UDP messages, a first end-to-end conununications path exists through a 
primary monitoring component, encapsulating component, and primary buffering 
component at a hub node, through ihe outbound channel from the hub node, fhsn 

20 through a remote terminal to a secondary monitoring component and decapsulating 
component, then to a secondary buffering component; for HTTP responses, a second 
end-to-end communications path exists from extemal server computers or traditional 
caches through the primary buffering component at a hub node, then through the 
outbound channel from the hub node, then through a remote terminal to the secondary 

25 monitoring component and then to the secondary buffering component. 

Those skilled in the art also will readily appreciate that many modifications to the 
invention are possible within the scope of the invention. Another alternative embodiment, 
to provide redimdancy, would include more than one PIC buffering component associated 
with a given end-user node. For mixed populations of CTid-user nodes, an intermediate 

30 node PIC Webcache can be implemented in networks that have some end-user nodes 
equipped vsdth PIC Webcaches and some that are not equipped with PIC Webcaches. 
Accordingly, the scope of flie invention is not intended to be limited to the preferred 
embodiments described above, but only by the appended claims. 
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CLAIMS 

We claim: 

1. A system of encapsulation and passive listening, comprising: 

a means hosted on a hub node of a network by which a message from a first network 
5 node to said hub node is encapsulated in a broadcast or multicast message and transmitted 
to one or more other network nodes unable to receive the original transmission of said 
message from said first network node to said hub node, 

a means associated with each of said one or more other network nodes of receiving, 
unencapsulating, and buffering said message when it arrives, and 
10 a means of storing the contents of the decapsulated and buffered message in cache 

memory or storage accessible by an end-user at each of said one or more other network 
nodes. 

2. A system of encapsulation and passive listening, comprising: 

a means hosted on a hub node of a network by which a message from a first network 
15 node to said hub node is selected for encapsulation based on one or more criteria, such as 

being an HTTP request or being addressed to a certain network address or socket, then 

encapsulated in a broadcast or multicast message and transmitted to one or more other 

network nodes imable to receive the original transmission of said message from said first 

network node to said hub node, 
20 a means associated with each of said one or more other network nodes of receiving, 

unencapsulating, and buffering said message when it arrives, and 

a means of storing the contents of the decapsulated and buffered message in cache 

memory or storage accessible by an end-user at each of said one or more other network 

nodes. 

25 3 . A system of encapsulation and passive listening, according to claim 1 or 2, wherein said 
message transmitted from said hub node to said one or more other network nodes is 
encapsulated in User Datagram Protocol or a transport layer, coimectionless protocol 
substantially equivalent to User Datagram Protocol, 
4. A system of socket matching, comprising: 

30 a means hosted on a hub node of a network by which an HTTP request from a first 

network node to said hub node is forwarded to a server computer and by which means a 
copy of said HTTP request is also transmitted to one or more other network nodes unable 
to receive the original transmission of said HTTP request &om said first network node to 
S£dd hub node, and by which means a copy of an HTTP response sent by said server 

35 computer in response to said HTTP request is transmitted to said first network node and 
to said one or more other network nodes, 

a means, associated with or interfaced with each of said one or more other network 
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nodes, of receiving and buffering said HTTP request when it arrives, and of receiving and 
bxififering said HTTP response when it arrives, in buffer memory associated with or 
interfaced with each of said one or more other network nodes, 

a means, associated with or interfaced with each of said one or more other network 
5 nodes, of matching the source socket and destination socket of a buffered HTTP request 
with the source socket and destination socket of a buffered HTTP response (the source and 
destination sockets are reversed in the HTTP request as compared with the HTTP 
response) sent by the server computer in response to said HTTP request and received 
before or after receipt of said HTTP request, and 
10 a means of storing imder the URL specified in the matching HTTP request the 

contents of the matched HTTP response in cache memory accessible to an end-user node, 
which end user node is associated with or interfaced with one of said one or more other 
network nodes. 

5. A system of socket matching, comprising: 

15 a means hosted on a hub node of a network by which an HTTP request jfrom a first 

network node to said hub node is forwarded to a server computer and by which means a 
copy of said HTTP request is buffered at said hub node until such time as an HTTP 
response sent by said server computer in response to said HTTP request is received, 
buffered, and matched as described below at said hub node, 

20 a means hosted on said hub node of matching the source socket and destination socket 

of said buffered HTTP request with the source socket and destination socket of said 
buffered HTTP response (the source and destination sockets are reversed in the HTTP 
request as compared with the HTTP response), 

a means hosted on said hub node of transmitting a matched HTTP response and the 

25 matching HTTP request to one or more other network nodes imable to receive the original 
transmission of said HTTP request firom said first network node to said hub node, 

a means, associated with or interfaced with each of said one or more other network 
nodes, of receiving and buffering said HTTP request when it arrives, and of receiving and 
buffering said HTTP response when it arrives, in buffer memory associated with or 

30 interfaced widi each of said one or more other network nodes, 

a means, associated with or interfaced with each of said one or more other network 
nodes, of matching the source socket and destination socket of a buffered HTTP request 
with the source socket and destination socket of a buffered HTTP response (the source and 
destination sockets are reversed in the HTTP request as compared with the HTTP 

35 response) sent by the server computer in response to said HTTP request and received 
before or after receipt of said HTTP request, and 

a means of storing under the URL specified in said matching HTTP request the 
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contents of said matched HTTP response in cache memory accessible to an end-user node, 
which end user node is associated with or inter&ced with one of said one or more other 
network nodes. 

6. A system of socket matching, according to claim 4 or 5, wherein Transmission Control 
5 Protocol or a transport layer protocol other than Transmission Control Protocol that uses 
the network addressing and routing capabilities of Intemet Protocol, or a protocol other 
than Hypertext Transport Protocol that uses paired network layer addressmg and transport 
layer ports inrequest/response, client/server exchanges substantially eqmvalentto such use 
in Hypertext Transport Protocol, is used. 
10 7. A system of socket matching, according to claim 4 or 5, wherein the network is a star 
topology network selected from the group consisting of very small aperture satellite, 
multichannel multipoint distribution service, local multipoint distribution service, 
instructional television fixed service, digital television broadcasting, and digital 
cablecasting. 

15 8. A system of socket matching, according to claim 4 or 5, wherein each said copy of an 
HTTP request is encapsulated in a broadcast or multicast message before transmission 
from said hub node and is decapsulated upon receipt and prior to buffering at each of said 
one of more other network nodes. 

9. A caching system for a star topology network, comprising: 

20 a hub node of the star topology network that receives HTTP requests from one or more 

remote temiinals, which hub node is interfaced with at least one external server computer 
and transmits UDP datagrams, HTTP requests, and HTTP responses in an outbound 
channel from said hub node of the star topology network, and 

one or more intermediate or end-user nodes of said network that receive said UDP 

25 datagrams, HTTP requests, and HTTP responses and which one or more intermediate or 
end-user nodes are associated with or interfaced with a means for socket-matching HTTP 
requests and HTTP responses and for storing in an end-user accessible cache the contents 
of a given HTTP response under the URL extracted from a correctly matched HTTP 
request. 

30 10. A caching system for a star topology network, comprising: 

a hub node of the star topology network that receives HTTP requests from one or more 
remote terminals, which hub node is interfaced with at least one external server computer, 
has a first means for socket-matching, and transmits UDP datagrams, HTTP requests, and 
HTTP responses in an outbound channel fix>m said hub node of the star topology network, 

35 and 

one or more intermediate or end-user nodes of said network that receive said UDP 
datagrams, HTTP requests, and HTTP responses and which one or more intermediate or 
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end-user nodes are associated with or interfaced with a second means for socket-matching 
HTTP requests and HTTP responses and for storing in an end-user accessible cache the 
contents of a given HTTP response under the URL extracted from a correctly matched 
HTTP request. 

1 1 . A caching system for a star topology network, comprising: 

a hub node of the star topology network that has access to one or more external 
server computers, and internal to the star topology network has associated with the hub 
node a primary monitoring component, an encapsulating component, and an outbound 
channel, 

a secondary monitoring component, a decf^sulating component, and a socket- 
matching buffering component associated with one or more intermediate node or end-user 
nodes interfaced with a remote terminal in the star topology network, 

at least one global cache associated with said buffering component and an end-user 
node, or where said buffering component is associated with an intermediate node, said at 
least one global cache either associated with said buffering component, or associated with 
an end-user node and interfaced with said buffering component, 

conomimications paths for UDP and HTTP messages from the hub node through 
the outbovmd channel to each buffering component, 

a means controlled by each associated or inter£u:ed buffering component of writing 
files or database records in each associated or interfaced global cache, 

wherein each global cache is accessible by at least one end-user node and contains 
information or data from said server computers, and 

at least one end-user node is able to exchange HTTP requests and HTTP responses with 
said hub node using the star network medium or a different telecommunications medium. 

12. A caching system for a star topology network, comprising: 

a hub node of the star topology network that has access to one or more external 
server computers, and internal to the star topology network has associated with the hub 
node a primary monitoring component, an encapsulating component, a socket-matching 
primary buffering component, and an outbound channel, 

a secondary monitoring component, a decapsulating component, and a socket- 
matching secondary bxrffering component associated with one or more intemiediate nodes 
or end-user nodes interfaced with a remote terminal in the star topology network, 

at least one global cache associated with said secondary buffering component and 
an end-user node, or where said secondary bviffering component is associated with an 
intermediate node, said at least one global cache is either associated with said secondary 
buffering component, or associated with an end-user node and interfaced with said 
secondary buffering component. 
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communications paths for UDP and HTTP messages from the hub node through 
the outbound channel to each secondary buffering component, 

a means controlled by each associated or interfaced secondary buffering component 
of writing files or database records m each associated or interfaced global cache, 

wherein each globed cache is accessible by at least one end-user node and contains 
information or data from said server computers, and 

at least one end-user node is able to exchange HTTP requests and HTTP responses 
vAUi said hub node using the star network medium or a different telecommunications 
medium. 

13. A caching system for a star topology network, according to claim 9, 10, 1 1, or 12, 
wherein Transmission Control Protocol or a transport layer protocol other than 
Transmission Control Protocol that uses network addressing and routing capabilities of 
Intemet Protocol is used, or a protocol other than Hypertext Transport Protocol that uses 
paired network layer addressing and transport layer ports in request/response, client/server 
exchanges substantially equivalent to such use in Hypertext Transport Protocol is used, or 
a connectionless protocol other than User Datagram Protocol with broadcast or multicast 
addressing substantially equivalent to that of User Datagram Protocol is used. 

14. A caching system for a star topology network, comprising: 

a hub node of the star topology network that has access to one or more extemal 
server computers, and internal to the star topology network has associated with the hub 
node a primary monitoring component, an encapsulating component, and an outboimd 
channel, 

at least one end-user node interfaced with a remote terminal in the star topology 
network, and eissociated with each such end-user node a secondary monitoring component, 
a decapsulating component, a socket-matching buffering component, and at least one 
global cache, 

- • - a first commimications path from the hub node through the primary monitoring 
component, encapsulating component, and outbound channel, thence through the remote 
terminal, the secondary monitoring component and decapsulating component to each said 
buffering component, 

a second communications path from said one or more extemal server computers 
through the outboimd channel of said hub node, thence through the remote terminal, the 
secondary monitoring component to each said buffering component, 

a means controlled by each said buffering component of writing files or database 
records in said associated global cache, 

wherein said global cache is accessible by said end-user node and contains 
information or data from said server computers, and 
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at least one end-user node is able to exchange messages with said hub node using 
the star network medium or a different telecommxmications medium. 
15. A caching system for a star topology network, comprising: 

a hub node of the star topology network that has access to one or more extemal 
5 server computers, and internal to the star topology network has associated with the hub 
node a primary monitoring component, an encapsulating component, and an outbound 
channel, 

at least one intermediate node interfaced witharemote terminal in the star topology 
network, and associated with each such intermediate node a secondary monitoring 
10 component, a decapsulating component, and a socket-matching bufTering component, 

at least one global cache associated with an end-user node and interfaced with said 
buffering component, 

a first coromimications path from the hub node through the primary monitoring 
component, encapsulating component, and outbound channel, thence through the remote 
1 5 terminal, the secondary monitoring component and decapsulating component to each said 
buffering component, 

a second communications path from said one or more extemal server computers 
through the outbound channel of said hub node, thence through the remote terminal, the 
secondary monitoring component to each said buffering component, 
20 a means controlled by said buffering component of writing files or database records 

in said interfaced global cache, 

wherein said global cache is accessible by said end-user node and contains 
information or data from said server computers, and 

at least one end-user node is able to exchange messages with said hub node using 
25 the star network medium or a different telecommxmications medium. 
16. A caching system for a star topology network, comprising: 

a hub node of the star topology network that has access to one or more extemal 
server computers, and internal to the star topology network has associated with the hub 
node a primary monitoring component, an encapsulating component, and an outbound 
30 channel, 

at least one intermediate node interfaced with a remote terminal in the star topology 
network and with at least one end-user node, and associated with each such intermediate 
node is a secondary monitoring component, a decapsulating component, a socket-matching 
buffering component, and at least one global cache, 
35 a first communications path from the hub node through the primary monitoring 

component, encapsulating component, and outboimd channel, thence through the remote 
terminal, the secondary monitoring component and decapsulating component to each said 
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buffering component, 

a second communications path from said one or more external server computers 
through the outbound chaimel of said hub node, thence through the remote terminal^ the 
5 secondary monitoring component to each said buffering component, 

a means controlled by each said buffering component of writing files or database 
records in said associated global cache, 

wherein each global cache is accessible by at least one end-user node interfaced 
with said intermediate node and contains information or data from said server computers, 
10 and 

at least one end-user node is able to exchange messages with said hub node using 
the star network medium or a dififerent telecommunications medium. 

17. A caching system for a star topology network, comprising: 

a hub node of the star topology network that has access to one or more external 
15 server computers, and internal to the star topology network has associated with the hub 
node a primary monitoring component, an encapsulating component, a socket-matching 
primary buffering component, and an outbound channel, 

at least one end-user node interfaced with a remote terminal in the star topology 
network, and associated with each such end-user node a secondary monitoring component, 
20 a decapsulating component, a socket-matching secondary buffering component, and at least^ 
one global cache, 

a first communications path from the hub node through said primary monitoring 
component, encapsulating component, primary buffering component, and outbound^ 
channel, thence through the remote terminal, said secondary monitoring component and 
25 decapsulating component to each said secondary buffering component, 

a second commimications path from said one or rnore external server computers 
through the primary monitoring component, primary buffering component, and outbound 
channel of said hub node, thence through the remote terminal, said secondary monitoring 
component to each said secondary buffering component, 
30 a means controlled by each secondary buffering component of writing files or 

database records in said associated global cache, 

wherein said global cache is accessible by said end-user node and contains 
information or data from said server computers, and 

at least one end-user node is able to exchange messages with said hub node using 
35 the star network medium or a different telecommunications mediirai. 

18. A caching system for a star topology network, comprising: 

a hub node of the star topology network that has access to one or more external 
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server computers, and internal to the star topology network has associated with the hub 
node a primary monitoring component, an encapsulating component, a socket-matching 
primary buffering component, and an outbound channel, 

at least one intermediate node interfaced with a remote terminal in the star topology 
5 network and interfaced with at least one end-user node, and associated with each such 
intermediate node a secondary monitoring component, a decapsulating component, and a 
socket-matching secondary buffering component, 

at least one global cache associated with each said end-user node and interfaced 
with said secondary buffering component, 
10 a first contununications path from the hub node through said primary monitoring 

component, encapsulating component, primary buffering component, and outbound 
channel, thence through the remote terminal, said secondary monitoring component and 
decapsulating component to each said secondary buffering component, 

a second commimications path from said one or more external server computers 
15 through the primary monitoring component, primary buffering component, and outbound 
channel of said hub node, thence through the remote terminal, said secondary monitoring 
component to each said secondary buffering component, 

a means controlled by each secondary buffering component of writing files or 
database records in said interfaced global cache, 
20 wherein said global cache is accessible by said end-user node and contains 

information or data firom said server computers, and 

at least one end-user node is able to exchange messages with said hub node using 
the star network medium or a different telecommunications medium. 
19. A caching system for a star topology network, comprising: 
25 a hub node of the star topology network that has access to one or more external 

server computers, and internal to the star topology network has associated with the hub 
node a primary monitoring component, an encapsulating component, a socket-matching 
primary buffering component, and an outboimd channel, 

at least one intermediate node interfaced with a remote temdnal in the star topology 
30 network, and associated with each such intermediate node a secondary monitoring 
component, a decapsulating component, a socket-matching secondary buffering 
component, and at least one global cache, 

a first cormnunications path from the hub node through said primary monitoring 
component, encapsulating component, primary buffering component, and outbound 
35 channel, thence through the remote terminal, said secondary monitoring component and 
decapsulating component to each said secondary buffering component, 

a second communications path from said one or more external server computers 
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through the primary monitormg component, primary buffering component, and outboxmd 
channel of said hub node, thence through the remote terminal, said secondary monitoring 
component to each said secondary buffering component, 

a means controlled by each said secondary buffering component of writing files or 
5 database records in said associated global cache, 

wherein each global cache is accessible by at least one end-user node interfaced 
with said intermediate node and contains information or data firom said server computers, 
and 

at least one end-user node is able to exchange messages with said hub node using 
10 the star network medium or a different teleconununications medium. 

20. A caching system for a star topology network, according to claim 9, 10, 11, 12, 14, 15, 
16, 17, 18, or 19, wherein the star networking technology is very small aperture satellite 
("VSAT"), multichannel multipoint distribution service ("MMDS"), local multipoint 
distribution service ("LMDS"), instructional television fixed service ("ITFS"), digital 

15 television broadcasting, or digital cablecasting. 

21. A caching system for a star topology network, according to claim 9, 10, 11, 12, 14, 15, 
16, 17, 18, or 19, wherein a Passive Internet Cache system concurrently uses one or more 
wireline outbound chaimels, wireless outbound channels, wireline inbound channels,, 
and/or wireless inbound channels. 

20 22. A caching system for a star topology network, according to claim 14, 15, 16, 17, 1 8, 
or 19, wherein the network layer protocol is Internet Protocol or a protocol that uses 
network addressing and routing substantially equivalent to that of Internet Protocol is used, 
the transport layer protocol used in the first communications path to encapsulate an HTTP 
request is User Datagram Protocol or a connectionless protocol substantially equivalent to 

25 that of User Datagram Protocol is used, the transport layer protocol used in the second 
communications path is Transport Control Protocol or a connection-oriented protocol 
substantially equivalent to Transport Control Protocol is used, or the applications and 
services protocol is a protocol other than Hypertext Transport Protocol that uses paired 
network layer addressing and transport layer ports in request/response, client/server 

30 exchanges substantially equivalent to that of Hypertext Transport Protocol. 

23. A caching system for a star topology network, according to claim 14, 15, 16, 17, 18, 
or 19, wherein caching through the second communications path to one or more global 
caches of specified URLs, or payloads of HTTP messages with specified IP addresses, is 
blocked or authorized by a content authorization program implemented through the first 

35 communications path. 

24. A caching system for a star topology network, according to claim 14, 15, 16, 17, 18, 
or 1 9, wherein the HTTP responses received through the second communications path are 
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examined by said buffering component associated with an intemiediate node or an end-user 
node, and if said buffering component detects one or more errors in the payload of an 
HTTP response, said buffering component discards each HTTP response containing such 
error(s) and the corresponding buffered HTTP request. 

25, A caching system for a star topology network, according to claim 14, 15, 16, 17, 18, 
or 19, wherein there is a means by which HTTP responses received through the second 
commimications path are examined by said buffering component associated with an 
intermediate node or an end-user node, and if said buffering component detects an error 
in the payload of an HTTP response and said buffering component is associated with or 
interfaced with an inbound chaimel, the buffering component extracts the relevant URL 
fix)m tiie corresponding decapsulated and buffered HTTP request, prepares an HTTP 
request for such URL, and causes the transmission of the prepared HTTP request in such 
inbovmd channel. 

26. A caching system for a star topology network, according to claim 14, 1 5, or 1 6, further 
comprising: 

a means by which each HTTP request inbound from a remote terminal is relayed to 
a server computer and a copy of said HTTP request is encapsulated in a UDP datagram at 
a hub node and distributed through the first communications path to all secondary 
monitoring components associated with or interfaced with an intermediate node or an end- 
user node in the star topology network, each of which secondary monitoring component 
forwards such encapsulated HTTP request to a decapsulating component associated with 
such secondary monitoring component, such decapsulating component decapsulates such 
HTTP request and forwards such decapsulated HTTP request to a buffering component 
associated with such decapsulating component, and such decapsulated HTTP request is 
tagged by the buffering component based on source socket and destination socket and 
buffered; and 

one or more remote terminals, each of which remote terminals is associated with or 
interfaced with an intermediate node or end-user node and has a means to output each 
HTTP response received through the second communications path to a secondary 
monitoring component associated with or interfaced with such intermediate node or end- 
user node, wherein such secondary monitoring component forwards such HTTP response 
to a buffering component associated with such secondary monitoring component, such 
buffering component examines the source socket and destination socket of such HTTP 
response and the source socket and destination socket of each HTTP request that has been 
buffered and either (a) if the buffering component matches such HTTP response with a 
buffered HTTP request that contains the corresponding source socket and destination 
socket (the source and destination sockets are reversed in the HTTP request as compared 



46 



wo 01/88761 



PCT/USOl/15575 



with the HTTP response), then the buffering component stores in a global cache associated 
with or interfaced with the bvififering component and accessible by one or more end-users 
the contents of the HTTP response under the URL contained in the HTTP request, or (b) 
if the buffering component can not match such HTTP response with a buffered HTTP 
5 request that contains a corresponding source socket and destination socket, such HTTP 
response is tagged by the buffering component based on source socket and destination 
socket of said HTTP response and buffered, then periodically thereafter the buffering 
component attempts to match the source socket and destination socket of such buffered 
HTTP response with subsequentiy buffered HTTP requests and upon successfully 

10 matching the sockets of such HTTP response with the sockets of an HTTP request (the 
source and destination sockets are reversed in the HTTP request as compared with the 
HTTP response), then the buffering component stores in a global cache associated with or 
interfaced with the buffering component and accessible by one or more end-users the 
contents of the HTTP response imder the URL extracted from in the HTTP request, and 

15 if the sockets of an HTTP response cannot be matched before the expiration of an operator- 
defined time, the buffering component discards such HTTP response; if the sockets of an 
HTTP request caimot be matched before the expiration of an operator-defined time, the 
buffering component discards such HTTP request unless the buffering component has 
access to a forward communications channel and in which case issues an HTTP request 

20 containing the URL in the unmatched and buffered HTTP request 

27. A caching system for a star topology network, according to claim 1 7, 1 8, or 19, furtiier 
comprising: 

a means by which each HTTP request inbound from a remote terminal is relayed to 
a server computer and a copy of such HTTP request is encapsulated in a UDP datagram 

25 at s£iid hub node and buffered in a primary buffering component pending the arrival at the 
hub node of a corresponding HTTP response, and upon arrival of such corresponding 
HTTP response, said HTTP response is buffered in said primary buffering component and 
said primary buffering component examines the source socket and destination socket of 
such HTTP reisfponse and the source socket and destination socket of each HTTP request 

30 that has been encapsulated and buffered and either (a) if tiie primary buffering component 
matches such buffered HTTP response with an encapsulated and buffered HTTP request 
that contains the corresponding source socket and destination socket (the source and 
destination sockets are reversed in the HTTP request as compared vsdth the HTTP 
response), then the primary buffering component forwards the encapsulated and matched 

35 HTTP request through the first communications path to all secondary monitoring 
components associated with or interfaced with an intermediate node or an end-user node 
in the star topology network, each of which secondary monitoring component forwards 
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such encapsulated HTTP request to a decapsulating component associated with such 
secondary monitoring component, such decapsulating component decapsulates such HTTP 
request and forwards such decapsulated HTTP request to a secondary buffering component 
associated with such decapsulating component, and such decapsulated HTTP request is 
5 tagged by the secondary buffering component based on source socket and destination 
socket and buffered, or (b) if the primary buffering component can not match an 
encapsulated buffered HTTP request with a buffered HTTP response that contains a 
corresponding source socket and destination socket, the primary buffering component 
either issues another HTTP request, without encapsulation, addressed to the relevant server 

10 computer and receives a corresponding HTTP response that the secondary buffering 
component successfully socket-matches, or discards such encapsulated and buffered HTTP 
request, as determined by operator-defined configuration settings, and only after 
forwarding of an encapsulated HTTP request through the first communications path under 
(a) above, the primary buffering component at the hub node forwards the matching HTTP 

15 response through the second communications channel, and 

a means associated with or interfaced with each intermediate node or end-user node 
that outputs each HTTP response received through the second communications path to a 
secondary monitoring component associated with or interfaced with such intermediate 
node or end-user node, wherein such secondary monitoring component forwards such 

20 HTTP resfponse to a secondary buffering component associated with such secondary 
monitoring component, such secondary buffering component examines the source socket 
and destination socket of such HTTP response and the source socket and destination socket 
of each HTTP request that has been buffered and either (a) if the secondary buffering 
component matches such HTTP response with a buffered HTTP request that contains the 

25 corresponding source socket and destination socket (the source and destination sockets are 
reversed in the HTTP request as compared with the HTTP response), then the secondary 
buffering component stores in a global cache associated with or interfaced with the 
secondary buffering component and accessible by one or more end-users the contents of 
the HTTP response under the URL contained in the HTTP request, or (b) if the secondary 

30 buffering component can not match such HTTP response with a buffered HTTP request 
that contains a corresponding source socket and destination socket, such HTTP response 
is tagged by the secondary buffering component based on source socket and destination 
socket of said HTTP response and buffered, then periodically thereafter the secondary 
buffering component attempts to match the source socket and destination socket of such 

35 buffered HTTP response with subsequentiy buffered HTTP requests and upon successfully 
matching the sockets of such HTTP response with the sockets of an HTTP request (the 
source and destination sockets are reversed in the HTTP request as compared with the 
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HTTP response), then the secondary buffering component stores m a global cache 
associated with or interfaced with the secondary buffering component and accessible by 
one or more end-iisers the contents of the HTTP response under the URL extracted from 
in the HTTP request, and if the sockets of an HTTP response cannot be matched before the 
5 expiration of an operator-defined time, the secondary buffering component discards such 
HTTP response; if the sockets of an HTTP request cannot be matched before the e:?q)iration 
of an operator-defined time, the secondary buffering component discards such HTTP 
request unless the secondary buffering component has access to a forward communications 
channel and in which case issues an HTTP request containing the URL in the unmatched 
10 and buffered HTTP request. 

28. A method of encapsulation and passive listening, comprising: 

receiving and buffering on a hub node of a network a message from a first network 
node to said hub node, encapsulating said message within a broadcast or multicast 
message, and transmitting said broadcast or multicast message to one or more other 

15 network nodes imable to receive the original message transmission from said first network 
node to said hub node, 

receiving said broadcast or multicast message, and imencapsulating and buffering said 
original message from said first node, when said broadcast or multicast message arrives 
at each of said one or more other network nodes, and 

20 storing the contents of the decapsulated and buffered message in cache memory or 

storage accessible by an end-user at each of said one or more other network nodes. 

29. A method of encapsulation and passive listening, comprising: 

receiving and buffering on a hub node of a network a message from a first network 
node to said hub node, selecting said message for encapsulation based on one or more 
25 criteria, such as being an HTTP request or being addressed to a certain network address or 
socket, encapsulating said message within a broadcast or multicast message, and 
transmitting said broadcast or multicast message to one or more other network nodes 
unable to receive the original message transmission from said first network node to said 
hub node, 

30 when said broadcast or multicast message arrives at each of said one or more other 

netwoik nodes, receiving said broadcast or multicast message, and unencapsulating and 
buffering said original message from said first node, at each of said one or more other 
network nodes, and 

storing the contents of the decapsulated and buffered message in cache memory or 
35 storage accessible by an end-user at each of said one or more other network nodes. 

30. A method of encapsulation and passive listening, according to claim 28 or 29, wherein 
said message transmitted from said hub node to said one or more other network nodes is 
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encapsiilated in User Datagram Protocol or a transport layer, connectionless protocol 
substantially equivalent to User Datagram Protocol. 

3 1 . A method of socket matching, comprising: 

receiving and bufifering on a hub node of a network an HTTP request from a first 
network node to said hub node, forwarding said HTTP request to a server computer and 
also copying said HTTP request and transmitting said HTTP request to one or more other 
network nodes unable to receive the original transmission of said HTTP request from said 
first network node to said hub node, receiving an HTTP response sent by said server 
computer in resfponse to said HTTP request, and transmitting said HTTP response to said 
first network node and to said one or more other network nodes, 

at each of said one or more other network nodes, receiving and buffering said HTTP 
request when it arrives, and receiving and buffering said HTTP response when it arrives, 
in buffer memory associated with or interfaced with each of said one or more other 
network nodes, 

in said buffer memory at each of said one or more other network nodes, matching the 
source socket and destination socket of a buffered HTTP request with the source socket 
and destination socket of a buffered HTTP response (the source and destination sockets are 
reversed in the HTTP request as compared with the HTTP response) sent by the server 
computer in response to said HTTP request and received before or after receipt of said 
HTTP request, and 

storing imder the URL specified in the matching HTTP request the contents of the 
matched HTTP response in cache memory accessible to an end-iiser node, which end user 
node is associated with or interfaced with one of said one or more other network nodes. 

32. A method of socket matching, comprising: 

receiving and buffering on a hub node of a network an HTTP request from a first 
network node to said hub node, forwarding said HTTP request to a server computer and 
also copying said HTTP request and buffering in buffer memory said copied HTTP 
request until such time as an HTTP response sent by said server computer in response to 
said HTTP request is received, buffered, and matched as described below at said hub node 

receiving and buffering at said hub node an HTTP response sent by said server 
computer in response to said HTTP request 

in said buffer memory said hub node, matching the source socket and destination 
socket of a buffered HTTP request v^th the source socket and destination socket of a 
buffered HTTP response (the source and destination sockets are reversed in the HTTP 
request as compared with the HTTP response) sent by the server computer in response to 
said HTTP request and received before or after receipt of said HTTP request, and 

transmitting said matched HTTP request from said hub node to one or more other 
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network nodes unable to receive the original transmission of said HTTP request from said 
first network node to said hub node, and transmitting said matching HTTP response to said 
first network node and to said one or more other network nodes, 

at each of said one or more other network nodes, receiving and buffering said HTTP 
5 request when it arrives, and receiving and buffering said HTTP response when it arrives, 
in buffer memory associated with or interfaced with each of said one or more other 
network nodes, 

in said buffer memory at each of said one or more other network nodes, matching tiie 
source socket and destination socket of a buffered HTTP request with the source socket 
1 0 and destination socket of a buffered HTTP response (the source and destination sockets are 
reversed in the HTTP request as compared with the HTTP response) sent by the server 
computer in response to said HTTP request and received before or after receipt of said 
HTTP request, and 

storing under the URL specified in the matching HTTP request the contents of the 
15 matched HTTP response in cache memory accessible to an end-user node, which end user 
node is associated with or interfaced with one of said one or more other network nodes. 

33. A method of socket matclung, according to claim 31 or 32, wherein Transmission 
Control Protocol or a transport layer protocol other than Transmission Control Protocol 
that uses network addressing and routing capabilities of Intemet Protocol, or a protocol 

20 other than Hypertext Transport Protocol that uses paired network layer addressing and 
transport layer ports in request/response, client/server exchanges substantially equivalent 
to that of Hypertext Transport Protocol, is used. 

34. A method of socket matching, according to claim 31 or 32, wherein the network is a 
star topology network selected from the group consisting of very small aperture satellite, 

25 multichannel multipoint distribution service, local multipoint distribution service, 
instructional television fixed service, digital television broadcasting, and digital 
cablecasting. * ' - 

35. A method of socket matching, according to claim 3 1 or 32, wherein each said copy of 
an HTTP request is encapsulated in a broadcast or multicast message before transmission 

30 from said hub node and is decapsulated upon receipt and prior to buffering at each of said 
one of more other network nodes. 

36. A caching method for a star topology network, comprising: 

receiving HTTP requests from one or more remote terminals at a hub node of the star 
topology network, interfacing said hub node with at least one external server computer, and 
35 transmitting UDP datagrams, HTTP requests, and HTTP responses in an outbound channel 
from said hub node of the star topology network, and 
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receiving said UDP datagrams, HTTP requests, and HTTP responses at one or more 
intermediate or end-user nodes associated with or interfaced with a remote terminal of said 
star topology network, socket-matching said HTTP requests and HTTP responses at said 
one or more intermediate or end-user nodes, and storing in an end-user accessible cache 
5 associated vnfh or inter&ced with said one or more intermediate or end-user nodes the 
contents of a given HTTP response under the URL extracted from a correctly matched 
HTTP request 

37. A caching method for a star topology network, comprising: 

receiving HTTP requests from one or more remote terminals at a hub node of the star 
10 topology network, interfacing said hub node with at least one external server computer, 
socket-matching HTTP requests and HTTP responses at said hub node, and transmitting 
UDP datagrams, HTTP requests, and HTTP responses in an outbound channel from said 
hub node of the star topology network to said one or more remote terminals, and 

receiving said UDP datagrams, HTTP requests, and HTTP responses at one or more 
1 5 intermediate or end-user nodes associated with or interfaced with a remote terminal of said 
star topology network, socket-matching said HTTP requests and HTTP responses at said 
one or more intermediate or end-user nodes, and storing in an end-user accessible cache 
at said one or more intermediate or end-user nodes the contents of a given HTTP response 
under the URL extracted from a correctly matched HTTP request 
20 38. A caching metiiod for a star topology network, comprising: 

interfacing a hub node of the star topology network with one or more external 
server computers, and internal to the star topology network associating with the hub node 
a primary monitoring component, an encapsulating component, and an outboimd channel, 
associating with at least one intermediate node or end-user node interfaced with a 
25 remote terminal in the star topology network a secondary monitoring component, a 
decapsulating component, and a socket-matching buffering component, 

associating with said buffering component and an end-user node at least one global 
cache, or where said buffering component is associated with an intermediate node, 
associating Avith or interfacing with said buffering component and an intermediate node at 
30 least one global cache, 

providing communications paths for UDP and HTTP messages from the hub node 
through the outboimd channel to each buffering component, 

controlling the writing of files or database records in said global cache by means 
of said associated or interfaced buffering component, 
35 wherein each global cache is accessible by at least one end-user node and contains 

information or data fix>m said server computers, and 

at least one end-user node is able to exchange HTTP requests and HTTP responses 
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wifh said hub node using the star network medium or a different telecommunications 
mediiim. 

1 39. A caching method for a star topology network, comprising: 

interfacing a hub node of the star topology network with one or more external 
5 server computers, and internal to the star topology network associating with the hub node 
aprimary monitoring component, an encapsulating component, a socket-matching primary 
buffering component, and an outbound channel, 

associating with at least one mtermediate node or end-user node interfaced, with a 
remote terminal in the star topology network a secondary monitoring component, a 
10 decapsulating component, and a socket-matching secondary buffering component, 

associating with said secondary buffering component and an end-user node at least 
one global cache, or where said secondary buffering component is associated with an 
intermediate node, associating with or interfacing with said secondary buffering 
component and an intermediate node at least one global cache, 
1 5 providing commimications paths for UDP and HTTP messages from the hub node 

through the outbound channel to each secondary biiffering component, 

controlling the writing of files or database records in said global cache by means 
of said associated or interfaced secondary buffering component, 

wherein each global cache is accessible by at least one end-user node and contains 
20 information or data from said server computers, and 

at least one end-user node is able to exchange HTTP requests and HTTP responses 
with said hub node using the star network medium or a different telecommunications 
medium. 

40. A caching method for a star topology network, according to claim 36, 37, 38, or 39, 
25 wherein Transmission Control Protocol or a transport layer protocol other than 
Transmission Control Protocol that uses the network addressing and routing capabilities 
of Internet Protocol is used, or a protocol other than Hypertext Transport Protocol that uses 
paired network layer addressing and transport layer ports in request/response, client/server 
exchanges substantially equivalent to such use in Hypertext Transport Protocol is used, or 
30 a connectionless protocol other than User Datagram Protocol with broadcast or multicast 
addressing substantially equivalent to that of User Datagram Protocol, is used. 
4L A caching method for a star topology network, comprising: 

interfacing a hub node of the star topology network with one or more extemal 
server computers, and internal to the star topology network associating with the hub node 
35 a primary monitoring component, an encapsulating component, and an outbound charmel, 
associating with at least one end-user node interfaced with a remote terminal in the 
star topology network a secondary monitoring component, a decapsulating component, a 
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socket-matching buffering component, and at least one global cache, 

providing a first commimications path from the hub node through the primary 
monitoring component, encapsulating component, and outbound channel, thence through 
the remote terminal, the secondary monitoring component and decapsulating component 
5 to each said buffering component, 

providing a second communications path from said one or more external server 
computers through the outbound channel of said hub node, thence through the remote 
terminal, the secondary monitoring component to each said buffering component, 

controlling the writing of files or database records in said associated global cache 
10 by means of said buffering component, 

wherein said global cache is accessible by said end-user node and contains 
information or data from said server computers, and 

at least one end-user node is able to exchange messages with said hub node using 
the star network medium or a different telecommxmications medium. 
15 42. A caching method for a star topology network, comprising: 

interfacing a hub node of the star topology network with one or more external server 
computers, and intemal to the star topology network associating v^th the hub node a 
primary monitoring component, an encapsulating component, and an outbound channel, 
associating with at least one intermediate node interfaced with a remote terminal in 
20 the star topology network a secondary monitoring component, a decapsulating component, 
and a socket-matching buffering component, 

associating at least one global cache with at least one end-user node interfaced vnih 
said buffering component, 

providing a first communications path from the hub node through the primary 
25 monitoring component, encapsulating component, and outbound channel, thence through 
the remote terminal, the secondary monitoring component and decapsulating component 
to each said buffering component, 

providing a second communications path from said one or more extemal server 
computers through the outboiind channel of said hub node, thence through the remote 
30 terminal, the secondary monitoring component to each said buffering component, 

controlling the writing of files or database records in said inter&ced global cache by 
means of said buffering component, 

M4ierein said global cache is accessible by said end-user node and contains information 
or data from said server computers, and 
35 at least one end-user node is able to exchange messages with said hub node using the 

star network medium or a different telecommxmications medium. 
43. A caching method for a star topology network, comprising: 
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interfacing a hub node of the star topology network with one or more external 
server computers, and intemal to the star topology network associating with the hub node 
a primary monitoring component, an encapsulating component, and an outboimd channel, 

associating with at least one intermediate node interfaced with a remote terminal 
5 in the star topology network a secondary monitoring component, a decapsulating 
component, a socket-matching bufTering component, and at least one global cache, 

providing a first communications path from the hub node tibrough the primary 
monitoring component, encapsulating component, and outboimd channel, thence through 
the remote terminal, the secondary monitoring component and decapsulating component 
10 to each said buffering component, 

providing a second communications path from said one or more external server 
computers through the outbound channel of said hub node, thence through the remote 
terminal, the secondary monitoring component to each said buffering component, 

controlling the writing of files or database records in said associated global cache 
15 by means of said buffering component, 

wherein each global cache is accessible by at least one end-user node interfaced 
with said intermediate node and contaios information or data from said server computers,^ 
and 

at least one end-user node is able to exchange messages with said hub node using 
20 the star network medium or a different telecommunications medium. 
44. A caching method for a star topology network, comprising: 

interfacing a hub node of the star topology network with one or more external 
server computers, and intemal to tiie star topology network associating with the hub node 
a primary monitoring component, an encapsulating component, a socket-matching primary 
25 buffering component, and an outboimd channel, 

associating with at least one end-user node interfaced with a remote terminal in the 
star topology network a secondary monitoring component, a decapsulating component, a 
socket-matching secondary buffering component, and at least one global cache, 

providing a first communications path &om the hub node through said primary 
30 monitoring component, encapsulating component, primary buffering component, and 
outbound channel, thence through the remote terminal, said secondary monitoring 
component and dec^sulating component to each said secondary buffering component, 

providing a second communications path from said one or more extemal server 
computers through the primary monitoring component, primary buffering component, and 
35 outbound channel of said hub node, thence through the remote terminal, said secondary 
monitoring component to each said secondary buffering component, 

controlling the writing of files or database records in said associated global cache 
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by means of said secondary buffering component, 

wherein said global cache is accessible by said end-user node and contains 
information or data jfrom said server computers, and 

at least one end-user node is able to exchange messages with said hub node using 
5 the star network medium or a different telecommunications medium. 
45. A caching method for a star topology network, comprising: 

interfacing a hub node of the star topology network with one or more external 
server computers, and intoxial to the star topology network associating witii the hub node 
aprimary monitoring component, an encapsulating component, a socket-matching primary 
10 buffering component, and an outbotmd channel, 

associating with at least one intemiediate node interfaced with a remote terminal 
in the star topology network a secondary monitoring component, a decapsulating 
component, and a socket-matching secondary buffering component, 

associating at least one global cache witii at least one end-user node interfaced with 
15 said secondary buffering component, 

providing a first communications path from the hub node through said primary 
monitoring component, encapsulating component, primary buffering component, and 
outbound channel, thence through the remote terminal, said secondary monitoring 
component and decapsulating component to each said secondary buffering component, 
20 providing a second communications path from said one or more external server 

computers through the primary monitoring component, primary buffering component, and 
outbound chaimel of said hub node, thence through the remote terminal, said secondary 
monitoring component to each said secondary buffering component, 

controlling the writing of files or database records in said interfaced global cache 
25 by means of said secondary buffering component, 

wherein said global cache is accessible by said end-user node and contains 
information or data from said server computers, and 

at least one end-user node is able to exchange messages vnOi said hub node using 
the star network medium or a different telecommunications medium. 
30 46. A caching method for a star topology network, comprising: 

interfacing a hub node of the star topology network with one or more external 
server computers, and internal to the star topology network associating vnih the hub node 
a primary monitoring component, an encapsulating component, a socket-matching primary 
buffering component, and an outboimd channel, 
35 associating with at least one intermediate node interfaced with a remote terminal 

in the star topology network a secondary monitoring component, a decapsulating 
component, a socket-matching secondary buffering component, and at least one global 
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cache, 

providing a first communications path from the hub node through said primary 
monitoring component, encapsulating component, primary buffering component, and 
outbound channel, thence through the remote terminal, said secondary monitoring 
5 component and decapsulating component to each said secondary buffering component, 

providing a second cormnunications path from said one or more extemal server 
computers through the primary monitoring component, primary buffering component, and 
outbound channel of said hub node, thence through the remote terminal, said secondary 
monitoring component to each said secondary buffering component, 
10 controlling the writing of files or database records in said associated global cache 

by means of said secondary buffering component, 

wherein each global cache is accessible by at least one end-user node interfaced 
with said intermediate node and contains information or data from said server computers, 
and 

15 at least one end-user node is able to exchange messages with said hub node using 

the star network mediima or a different telecommunications mediimi. 

47. A caching method for a star topology network, according to claim 36, 37, 38, 40, 41^ 
42, 43, 44, 45, or 46, wherein the star networking technology is very small aperture 
satellite ("VSAT"), multichannel multipoint distribution service C'MMDS"), local 

20 multipoint distribution service C*LMDS"), instructional television fixed service ("ITFS")^ 
digital television broadcasting, or digital cablecasting. 

48. A caching method for a star topology network, according to claim 36, 37, 38, 40, 41, 
42, 43, 44, 45, or 46, wherein a Passive Internet Cache system concurrently uses one or 
more wireline outbound channels, wireless outbound channels, wireliae inbound channels, 

25 and/or wireless inbound channels. 

49. A caching method for a star topology network, according to claim 41, 42, 43, 44, 45, 
or 46, wherein the network layer protocol is Internet Protocol or a protocol that uses 
network addressing and routing substantially equivalent to that of Intemet Protocol is used, 
the transport layer protocol used in the first communications path to encapsulate an HTTP 

30 request is User Datagram Protocol or a connectionless protocol substantially equivalent to 
that of User Datagram Protocol is used, the transport layer protocol used in the second 
communications path is Transport Control Protocol or a connection-oriented protocol 
substantially equivalent to Transfport Control Protocol is used, or the applications and 
services protocol is a protocol other than Hypertext Transport Protocol that uses paired 

35 network layer addressing and transport layer ports in request/response, client/server 
exchanges substantially equivalent to that of Hypertext Transport Protocol. 

50. A caching method for a star topology network, according to claim 41, 42, 43, 44, 45, 
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or 46, wherein caching through the second communications path to one or more global 
caches of specified URLs, or payloads of HTTP messages with specified IP addresses, is 
blocked or authorized by a content authorization program implemented through the first 
commimications path. 

51. A caching method for a star topology network, according to claim 41, 42, 43, 44, 45, 
or 46, wherein the HTTP responses received through the second commimications patii are 
examined by said buffering component associated with an intermediate node or an end-user 
node, and if said buffering component detects one or more errors in the payload of an 
HTTP response, said buffering component discards each HTTP response containing such 
enx)r(s) and the corresponding buffered HTTP request. 

52. A caching method for a star topology network, according to claim 41, 42, 43, 44, 45, 
or 46, wherein there is a means by which HTTP responses received through the second 
commimications path are examined by said buffering component associated with an 
intermediate node or an end-user node, and if said buffering component detects an error 
in the payload of an HTTP response and said buffering component is associated with or 
interfaced with an inbound channel, the buffering component extracts the relevant URL 
from the corresponding decapsulated and buffered HTTP request, prepares an HTTP 
request for such URL, and causes the transmission of the prepared HTTP request in such 
inbound channel. 

53. A caching method for a star topology network, according to claim 41, 42, or 43, 
furdier comprismg: 

relaying each HTTP request inbound firom a remote terminal through the hub node to 
a server computer and encapsulating a copy of each said HTTP request in a UDP datagram 
at said hub node, distributing said UDP datagram through the first communications path 
to all secondary monitoring components associated with or interfaced with an intermediate 
node or an end-user node in the star topology network, forwarding such encapsulated 
HTTP request firom each such secondary monitoring component to a decapsulating 
component associated witii each such secondary monitoring component, decapsulating 
such HTTP request in the decapsulating component, forwarding such decapsulated HTTP 
request firom such decapsulating component to a buffering component associated with such 
decapsulating component, and tagging by such buffering component of each such 
decapsulated HTTP request based on source socket and destination socket and buffered; 
and 

associating with or interfacing with one or more remote terminals an intermediate 
node or end-user node, outputting from each such remote terminal each HTTP response 
received through the second communications path to a secondary monitoring component 
associated with or interfaced with such intermediate node or end-user node, forwarding 
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from the secondaiy monitoring component such HTTP response to a buffering component 
associated with such secondary monitoring component, examining the source socket and 
destination socket of such HTTP response and the source socket and destination socket of 
each HTTP request that has been bxiffered by such buffering component, and either (a) if 
5 the buffering component matches such HTTP response with a buffered HTTP request that 
contains the corresponding source socket and destination socket (the source and destination 
sockets are reversed in the HTTP request as compared with the HTTP response), then 
storing by the buffering compon^t in a global cache associated witii or interfaced with the 
secondary buffering component and accessible by one or more end-users flxe contents of 

10 the HTTP response under the URL contained in the HTTP request, or (b) if the buffering 
component can not match such HTTP response with a buffered HTTP request that contains 
a corresponding source socket and destination socket, tagging such HTTP response by the 
buffering component based on source socket and destination socket of said HTTP response 
and buffering such tagged HTTP response, then periodically thereafter attempting by the 

15 buffering component to match the soxirce socket and destination socket of such buffered 
HTTP response with subsequently buffered HTTP requests and upon successfully 
matching the sockets of such HTTP response with the sockets of an HTTP request (the 
source and destination sockets are reversed in the HTTP request as compared with the 
HTTP re^onse), storing by the buffering component in a global cache associated with or 

20 interfaced with the secondaiy buffering component and accessible by one or more end- 
users the contents of the HTTP response under the URL extracted from in tiie HTTP 
request, and if the sockets of an HTTP response cannot be matched before the expiration 
of an operator-defined time, discarding by the buffering component of such HTTP 
response; if the sockets of an HTTP request cannot be matched before the expiration of an 

25 operator-defined time, discarding by the buffering component of such HTTP request unless 
the buffering component has access to a forward communications channel and in which 
case issuing by the buffering component of an HTTP request containing the URL in the 
unmatched and buffered HTTP request. 

54. A caching method for a star topology network, according to claim 44, 45, or 46, 

30 frirther comprising: 

relaying each HTTP request inbound from a remote terminal through the hub node to 
a server computer and encapsulating a copy of each said HTTP request in a UDP datagram 
at said hub node, buffering said UDP datagram in a primary buffering component pending 
the arrival at the hub node of a corresponding HTTP response, and upon arrival of such 

35 corresponding HTTP response, buffering said HTTP response in said primary buffering 
component, examining by said primary buffering component of the source socket and 
destination socket of such HTTP response and the source socket and destination socket of 
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each HTTP request that has been encapsulated and buffered and either (a) if the primary 
bufifering component matches such buffered HTTP response with an encapsulated and 
buffered HTTP request that contains the corresponding source socket and destination 
socket (the source and destination sockets are reversed in the HTTP request as compared 
5 with the HTTP response), forwarding by the primary buffering component of the 
encapsulated and matched HTTP request through the first communications path to all 
secondary monitoring components associated with or interfaced with an intermediate node 
or an end-user node in the star topology network, forwarding by each such secondary 
monitoring components of such encapsulated HTTP request to a decapsulating component 

1 0 associated with such secondary monitoring component, decapsulatmg by the decapsulating 
component of such HTTP request, forwarding such decapsulated HTTP request to a 
secondary buffering component associated with such decapsulating component, and 
tagging of such decapsulated HTTP request by the secondary buffering component based 
on source socket and destination socket and buffered, or (b) if the primary buffering 

15 component cannot match an encapsulated buffered HTTP request with a buffered HTTP 
response that contains a corresponding source socket and destination socket, either issuing 
by the primary buffering component of another HTTP request, witfiout encapsulation, 
addressed to the relevant server computer and receiving a corresponding HTTP response 
that the secondary buffering component successfully socket-matches, or discarding such 

20 encapsulated and buffered HTTP request, as determined by operator-defined configuration 
settings, and only after forwarding of an encapsulated HTTP request through the first 
communications path xmder (a) above, forwarding by the primary buffering component at 
the hub node of the matching HTTP response through the second communications chaxmel, 
and 

25 associating with or interfacing with one or more remote terminals an intermediate 

node or end-user node, outputting fi-om each such remote terminal each HTTP response 
received through the second communications path to a secondary monitoring component 
associated with or interfaced with such intermediate node or end-user node, forwarding 
&om the secondary monitoring component such HTTP response to a secondary buffering 

30 component associated with such secondary monitoring component, examining the source 
socket and destination socket of such HTTP response and the source socket and destination 
socket of each HTTP request tihat has been buffered by such secondary buffering 
component, and either (a) if the secondary buffering component matches such HTTP 
response with a buffered HTTP request that contains the corresponding soiirce socket and 

35 destination socket (the source and destination sockets are reversed in the HTTP request as 
compared with the HTTP response), then storing by the secondary buffering component 
in a global cache associated with or interfaced with the secondary buffering component and 
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accessible by one or more end-users the contents of the HTTP response under the URL 
contained in the HTTP request, or (b) if the secondary buffering component can not match 
such HTTP response with a buffered HTTP request that contains a corresponding source 
socket and destination socket, tagging such HTTP response by the secondary buffering 
component based on source socket and destination socket of said HTTP response and 
buffering such tagged HTTP response, then periodically thereafter attempting by the 
secondary buffering component to match tide source socket and destination socket of such 
buffered HTTP response with subsequently buffered HTTP requests and upon successfully 
matching the sockets of such HTTP response with the sockets of an HTTP request (the 
source and destination sockets are reversed in the HTTP request as compared with the 
HTTP response), storing by the secondary buffering component in a global cache 
associated with or inter&ced with the secondary buffering component and accessible by 
one or more end-users the contents of the HTTP response under the URL extracted from 
in the HTTP request, and if the sockets of an HTTP response cannot be matched before the 
expiration of an operator-defined time, discarding by the secondary buffering component 
of such HTTP response; if the sockets of an HTTP request cannot be matched before the 
expiration of an operator-defined time, discarding by the secondary buffering component 
of such HTTP request unless the secondary buffering component has access to a forward 
communications channel and in which case issuing by the secondary buffering component 
of an HTTP request containing the URL in the unmatched and buffered HTTP request. 
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